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NEW GUARDS FOR APPLICATION IN 
SOFTWARE TAMPERPROOFING 

This patent application claims the benefit of U.S. Provisional Application No. 

5 60/396,186, filed July 16, 2002; and is a continuation-in-part of U.S. Application No. 

09/455,580, filed December 6, 1999, which claims the benefit of U.S. Provisional Application 

No. 60/152,769, filed September 3, 1999. The disclosure of each above-referenced application is 

hereby incorporated by reference in its entirety. 

10 BACKGROUND 

In the modem software industry, software program vendors suffer huge losses due to the 
illegal distribution of software programs, a practice known commonly as software piracy. Part of 
the problem of software piracy is due to the fact that software programs, distributed as electronic 
files, are vulnerable to modifications by users. Thus, even those software programs that enforce 

15 online registrations prior to their legal use as a means of preventing unauthorized use can be 
modified by a malicious user (a "hacker") to bypass the online registration process. Such 
compromised software programs can be massively dupUcated and distributed, particularly in 
countries that do not provide the same legal protections to copyright owners as are found under 
United States law, and also in countries where software program vendors have less control over 

20 their products. As a result, software copyright owners lose significant revenue from lost sales 
and the development of competitive programs based on pirated copies of the copyrighted 
software. 

It is known in the art to embed security mechanisms in the software program code in an 
attempt to hinder the efforts of hackers. One such mechanism well known in the art is to require 
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the initial user to input a serial number into the software program prior to the initial use of the 
software program. The software program then will apply this serial number to an embedded 
algorithm to compute the true serial number of the software program, thereby validating the 
authenticity of the software program copy. This type of embedded security mechanism and 
others Uke it are vulnerable to compromise because such mechanisms often are based entirely on 
a few machine instructions within the software program. For example, many software programs 
use only a single instruction, typically a conditional jump, to compare the serial number entered 
by the initial user with the serial number computed by the software program to determine 
whether the software program copy is authentic. The use of a single instruction for this 
important security step provides the hacker with a single point of attack to defeat the security 
mechanism. To defeat such a mechanism, the hacker merely needs to find the conditional 
instruction in the code and replace it in the binary file with an unconditional instruction that 
advances the execution flow of the software program to the desired location, bypassing the serial 
number comparison step. Another approach employed by hackers to defeat such a security 
mechanism is to insert a sequence of small null operations that do nothing except advance the 
execution flow of the software program to the desired location naturally. Either kind of 
modification allows illegal sofl^vare program users to fireely run the compromised software 
programs. 

There are several more advanced security mechanisms known in the art, but their results 
and applicability have not been promising to the software industry. One such advanced security 
mechanism uses special hardware that directly executes an encrypted sofl:ware program without 
the software program's underlying binary code ever being disclosed in memory. The details of 
this method are disclosed in United States Patent No. 4,465,901 to Best . Further disclosure of a 
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similar method is made by White et al. in an article entitled "ABYSS: An Architecture for 
Software Protection," published in IEEE Transactions on Software Engineering, 16(6):6 19-629, 
June 1990. While this approach solves the problem, it has a major disadvantage in that 
encryption keys and special hardware are required for encrypting and executing the software 
5 program. Because of the need for encryption keys and special hardware, the result is a security 
mechanism that is more expensive and provides less user flexibility than a security mechanism 
which relies entirely on software-based techniques. 

Another security mechanism known in the art is the use of code obfiiscation, which 
makes the code difficult for a hacker to understand and analyze. Methods of code obfuscation 

10 are disclosed by CoUberg et al. in an article entitled, "Breaking Abstractions and Unstructuring 
Data Structures," published in IEEE International Conference on Computer Languages, 
ICCU98, Chicago, IL, USA, May 1998.; by Collberget al in an article entitled, "A Taxonomy of 
Obfuscating Transformations," published as Technical Report 148, Department of Computer 
Science, The University of Auckland, Private Bag 92019, Auckland, New Zealand, 1998; by 

15 Bashar et al. in an article entitled, "Low-Threat Security Patches and Tools," published as 
Technical Report CSD-TR-96-075, Coast TR 97-10, COAST Laboratory, Department of 
Computer Sciences, Purdue University, 1996; and by Mambo et al. in an article entitled, "A 
Tentative Approach to Constructing Tamper-Resistant Software," published in New Security 
Paradigms Workshop, Proceedings, pages 23-33, New York, NY, USA, 1998. Unfortunately, 

20 techniques currently known in the art of code obfuscation still are not adequate to prevent 
sophisticated software program hackers from identifying and modifying attack targets in the 
code. 
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Joepgen et aL disclose in their article entitled, "Software by Means of the 'Protprog* 
Method, Part 11" published in Elektronik, 42(17):52-56, Aug. 1993, a security mechanism 
utiUzing "self-modifying code," wherein the software program code generates other code at run- 
time. 

Schulman discloses in his article entitled, "Examining the Windows AARD Detection 
Code," published in Dr, Dobb's Journal, 18(9):42,44-8,89, Sept. 1993, another security 
mechanism utilizing code encryption and decryption, wherein partially encrypted code self- 
decrypts at run-time. 

Aucsmith discloses in his article entitled, "Tamper Resistant Software: An 
hnplementation," Ross Anderson, editor, pubUshed in Information Hiding — Proceedings of the 
First International Workshop, volume 1174 of LNCS, pages 317-333, May/June 1996, yet 
another security mechanism which utilizes a hybrid of the self-modifying code technique and the 
code encryption/decryption technique. U.S. Patent No. 5,892,899 to Aucsmith et al. discloses a 
similar mechanism. 

Several disadvantages are present in the prior art security mechanisms. First, the 
mechanisms which utilize self-modifying and self-decrypting code produce an extra burden on 
the computing resources at run-time. Second, the Litegrity Verification Kernels ("IVK") 
disclosed by Aucsmith in his article are relatively large segments of code. Because the IVKs 
must be decrypted during program execution and then subsequently encrypted, the program 
execution performance degrades, hi addition, the design of Aucsmith's IVKs make the IVK 
concept difficult to apply to larger IVKs. The processing time involved in decrypting and 
encrypting the larger IVKs may degrade program execution performance to the point where it is 
intolerable to the end-user. Furthermore, the first cell of each IVK is unencrypted. The large 
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size of the IVKs and the presence of the unencrypted first cell may provide clues to a hacker as to 
the location of the security mechanism within the code. Third, the security mechanism disclosed 
by Aucsmith in his article requires special services from the operating system software for proper 
execution. The resultant interaction between the security mechanism and the operating systems 
5 software may direct a hacker to the location of the security mechanism or to sensitive areas of the 
code. Finally, most prior art security mechanisms produce immediate program execution failures 
upon tampering. Such immediate failures provide additional clues for hackers as to the location 
of the security mechanisms or the sensitive areas of the code. 

Thus, such prior art software security mechanisms tend to be restricted in their 

10 applicability, and they have not been widely adopted by the software industry. It is desired in the 
software industry to develop a method for protecting a software application program from 
unauthorized modification which will not require special hardware, self-modifying code, or code 
encryption and decryption. It is further desired that the method will not require special operating 
system services and that the method will produce subtle errors rather than immediate program 

15 failure. 

SUMMARY 

An embodiment of the present invention comprises a software-only method for solving 
the software program security problem. The method of this embodiment utilizes self-protecting 
20 code ("SPC"), whereby a software program is armed internally with self-protection mechanisms 
that may render the software program unusable whenever its protected code is tampered with. 
The software program's self-protection mechanism is transparent to normal users. If no software 
program tampering has occurred, the software program executes normally as if it was 
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unprotected. If tampering has occurred, the SPC operates to interrupt normal application 
software program execution. The SPC may modify the software program instructions or 
software program data which resides in the computer's random access memory. The modified 
instructions or data will not become evident until the next time the software program accesses the 
5 memory location containing the instructions or data. The end result will be erroneous software 
program execution such as errors in the results of mathematical algorithms. At its extreme case, 
the end result may be complete failure of program execution. Alternatively, the SPC may be 
designed to operate in a less transparent manner. It may operate to halt program execution 
immediately, or may cause a message to be sent to the user's computer terminal or printer, or may 

10 caused a message to be stored in computer memory for fiiture use by the software program. The 
method may utilize, but does not require, cryptographic techniques. 

An embodiment of the present invention comprises a system that may comprise a 
computer program which receives as input at least one assembly language software program, 
object code software program, or binary executable software program to be protected, a set of 

15 optional watermarks to be embedded into the assembly language software programs, a set of 
object files or libraries with which the set of assembly language software programs will be 
linked, and the customization parameters required by method of the present invention. The 
output of the system will be a binary executable software program with embedded SPC. The 
system of the present invention may comprise part of a standard compiler for use with a high- 

20 level computer programming language. In an embodiment, the operation of the system is 
automatic. 

In an embodiment, the present invention comprises a method for adding tamper resistance 
to a software program, the method comprising the step of installing a plurality of guards in a 
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software program, each of the pluraUty of guards comprising at least one program instruction, 
wherein each of the plurality of guards is operable to verify the integrity of at least one program 
instruction of at least one other of the plurality of guards, and wherein the integrity of at least one 
program instruction of each of the plurality of guards is verified by at least one other of the 
5 plurality of guards. In an aspect of this embodiment, the method further comprises the step of 
generating an executable version of the software program having the plurality of guards installed 
therein, so that the program instructions of the plurality of guards are executed by running the 
executable version of the software program. 

In an embodiment, the present invention comprises a method for adding tamper resistance 

10 to a software program, the method comprising the steps of storing a first integer a in the software 
program; storing a multiplicative product pq of a second integer p and a third integer q in the 
software program; identifying a code block in the software program, the code block comprising 
at least one program instruction of at least one other of the plurahty of guards; computing a value 
C for the code block, the value C being computed in a manner that makes it likely that the value 

15 C would change if the code block is modified; computing a multiphcative inverse C\ the 
multiphcative inverse C satisfying the following: C * C modulo {p - \){q - \) = \\ computing a 
constant R according to the following: R = cf' modulo pq\ and storing the constant R in the 
software program. In an aspect of this embodiment, the method further comprises the steps of 
running the software program, thereby causing the program instructions of the plurality of guards 

20 to be executed; and for at least one code block in the software program, while the software 
program is running, computing a value X for the at least one code block, the value X being 
computed in the same manner as was the value C for the at least one code block, and taking a 
defensive action if: i?^ modulo pq a. 
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In an embodiment, the present invention comprises a method for adding tamper resistance 
to a software program, the method comprising the steps of selecting an asymmetric encryption 
key pair comprising a public key and a private key; storing the public key in the software 
program; identifying a code block in the software program, the code block comprising at least 
5 one program instruction of at least one other of the plurality of guards; calculating a baseline 
value for the code block, the baseline value being computed in a manner that makes it likely that 
the value would change if the code block is modified; encrypting the baseline value using the 
private key; and storing the encrypted baseUne value in the software program. Li an aspect of 
this embodiment, the method fiirther comprises the steps of running the software program, 

10 thereby causing the program instructions of the plurality of guards to be executed; and for at least 
one code block in the software program, while the software program is running, computing a 
runtime value of the at least one code block, the runtime value being computed in the same 
manner as was the baseline for the at least the one code block, decrypting the baseline value 
using the pubUc key, and taking a defensive action if the decrypted baseline value is not the same 

15 as the runtime value. 

hi an embodiment, the present invention comprises a method for producing tamper 
resistant copies of a software program, the method comprising the steps of installing a first 
watermark in a first copy of a software program; installing a second watermark in a second copy 
of a software program; installing a watermark guard in the first copy of a software program, the 

20 watermark guard comprising at least one program instruction, the watermark guard being 
operable to verify the integrity of the first watermark; and installing the watermark guard in the 
second copy of the software program, the watermark guard being operable to verify the integrity 
of the second watermark, wherein the watermark guard is installed in the same location in the 
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second copy of the software program as in the first copy of the software program. In an aspect 
this embodiment, the method further comprises the step of instaUing at least one other guard in 
the first copy of the software program and the second copy of the software program, each of the 
at least one other guards comprising at least one program instruction, wherein at least one of the 
5 at least one other guards is operable to verify the integrity of at least one program instruction of 
the watermark guard, wherein each the at least one other guard is the same in, and is installed in 
the same location in, the first copy of the software program and the second copy of the software 
program. 

In an embodiment, the present invention comprises a method for producing a plurality of 
10 tamper resistant copies of a software program, the method comprising the steps of storing a first 
integer V in all of the pluraHty of copies of the software program; storing a multiplicative product 
pq of a second integer p and a third integer q in all of the plurality of copies of the software 
program; storing a one-way function HQ in all of the plurality of copies of the software program; 
and for each of the plurality of copies of the software program, storing a watermark Win the copy 
15 of the software program, generating H(W) comprising a result of executing one-way function H() 
with watermark W comprising an input argument thereto, computing a multiplicative inverse W 
satisfying the following: W* * H(W) modulo (p-l)(^-l) = l, computing a constant Q according 
to the following: Q = modulo pq, and storing the constant Q in the copy of the software 
program. In an aspect this embodiment, the method further comprises, for at least one of the 
20 plurality of copies of the software program, the steps of running the at least one of the plurality of 
copies of the software program; and taking a defensive action if: ^^^^ modulo pq ^ V. 

In an embodiment, the present invention comprises a method for producing a plurality of 
tamper resistant copies of a software programs, the method comprising the steps of selecting an 
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asymmetric encryption key pair comprising a public key and a private key; storing the public key 
in the software program in all of the plurality of copies of the software program; storing a one- 
way function in all of the plurality of copies of the software program; and for each of the pluraUty 
of copies of the software program, storing a watermark in the copy of the software program, 
5 generating a baseline value comprising the result of executing the one-way function with the 
watermark comprising an input argument thereto, encrypting the baseHne value with the private 
key, and storing the encrypted baseline value in the software program. In an aspect of this 
embodiment, the method further comprises, for at least one of the plurality of copies of the 
software program, the steps of running the at least one of the plurality of copies of the software 

10 program; while the executable version is running, generating a runtime value comprising the 
result of executing the one-way function with the watermark comprising an input argument 
thereto; decrypting the baseline value; and taking a defensive action if the runtime value differs 
from the decrypted baseline value. 

In an embodiment, the present invention comprises a method for producing a software 

15 program comprising mutually reliant program parameters, the method comprising the steps of 
storing a first integer F in a software program; storing a multiplicative product pq of a second 
integer p and a third integer q in the software program; storing a one-way fimction HQ in the 
software program; storing one or more program parameters in the software program; generating 
baseline constant U comprising two or more of the program parameters; generating baseline 

20 value the baseline value J comprising a result of executing one-way function HQ with baseline 
constant U comprising an input argument thereto; computing a multiplicative inverse C/' 
satisfying the following: V * J modulo (p-l)(9-l) = l; computing a constant Q according to 
the following: Q = modulo pq; and storing the constant Q in the software program. In an 
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aspect of this embodiment, the method further comprises the steps of rumiing the software 
program; while the software program is rumiing, generating runtime constant U comprising two 
or more of the program parameters; generating runtime value K, the runtime value K comprising 
a result of executing one-way function HQ with runtime constant U comprising an input 

5 argument thereto; and taking a defensive action if modulo pq ^ V. 

In an embodiment, the present invention comprises a method for producing a software 
program comprising mutually reliant program parameters, the method comprising the steps of 
selecting an asymmetric encryption key pair comprising a public key and a private key; storing 
one or more program parameters in the software program; storing the public key in the software 

10 program; generating baseline constant U comprising two or more of the program parameters; 
generating baseline value 7, the baseline value J comprising a result of executing one-way 
function H() with baseline constant U comprising an input argument thereto; encrypting the 
baseline value J with the private key; and storing the encrypted baseline value J in the software 
program, In an aspect of this embodiment, the method further comprises the steps of running the 

15 software program; while the software program is running, generating runtime constant U 
comprising two or more of the program parameters; generating runtime value the runtime 
value K comprising a result of executing one-way function HQ with runtime constant U 
comprising an input argument thereto; decrypting the baseline value /; and taking a defensive 
action if the runtime value K differs firom the decrypted baseline value 

20 In an embodiment, the present invention comprises a method for producing a plurality of 

tamper resistant copies of a software program wherein each copy of the software program 
comprises mutually reliant program parameters, the method comprising the steps of installing 
two or more program parameters in a first copy of a software program; generating a first value 
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comprising the two or more program parameters installed in the first copy of the software 
program, the first value being likely to change if one or more of the program parameters installed 
in the first copy of the software program is changed; storing the first value in the first copy of the 
software program; installing two or more program parameters in a second copy of a software 
5 program; generating a second value comprising the two or more program parameters installed in 
the second copy of the software program, the second value being likely to change if one or more 
of the program parameters installed in the second copy of the software program is changed; 
storing the second value in the second copy of the software program; installing a program 
parameter guard in the first copy of a software program, the program parameter guard comprising 

10 at least one program instruction, the program parameter guard being operable to verify the 
integrity of the first value; and installing the program parameter guard in the second copy of the 
software program, the program parameter guard being operable to verify the integrity of the 
second value, wherein the program parameter guard is installed in the same location in the 
second copy of the software program as in the first copy of the software program. 

15 In an embodiment, the present invention comprises a method for adding tamper resistance 

to a software program, the method comprising the steps of identifying a first code block in a 
sofl:ware program; creating a second code block, the second code block comprising a copy of the 
first code block; disguising the second code block; and installing at least one repair guard in the 
software program, each of the at least one repair guards comprising at least one program 

20 instruction. In an aspect of this embodiment, the method further comprises the steps of executing 
the at least one program instruction of at least one of the at least one repair guards; undisguising 
the second code block; and overwriting the first client code block with the undisguised second 
code block copy. 



P00620-US-01 



12 



In an embodiment, the present invention comprises method for adding tamper resistance 
to a software program, the method comprising the steps of instalHng a piuraUty of guards in a 
software program, each of the plurality of guards comprising at least one guard program 
instruction; and installing guard selection program instructions in the software program, the 
5 guard selection program instructions being operable to alter the control flow of the software 
program, hi an aspect of this embodiment, the guard selection program instructions, when 
executed during running of the software program, alter the control flow of the software program 
by causing the execution of one or more of the guard program instructions to be skipped. In an 
aspect of this embodiment, wherein one or more of the guard program instructions ordinarily 
10 would not be executed when running the software program, the guard selection program 
instructions, when executed during running of the software program, alter the control flow of the 
software program by causing at least one of the one or more of the guard program instructions to 
be executed. 

In an embodiment, the present invention comprises a method for adding tamper resistance 
15 to a software program, the method comprising the steps of instaUing two or more repair guards in 
a software program, each the repair guard comprising one or more program instruction that, when 
executed during running of the software program, are operable to overwrite one or more program 
instructions of the software program with properly fimctioning program instructions; installing 
guard selection program instructions in the software program, the guard selection program 
20 instructions, when executed during the running of the software program, causing one or more of 
the repair guards to be executed: 

In an embodiment, the present invention comprises a recordable computer readable media 
having a tamper resistant software program recorded thereon, comprising a plurality of guards 
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installed in a software program, each of the plurality of guards comprising at least one program 
instruction, wherein each of the plurality of guards is operable to verify the integrity of at least 
one program instruction of at least one other of the plurality of guards, and wherein the integrity 
of at least one program instruction of each of the plurality of guards is verified by at least one 
5 other of the plurality of guards. 

In an embodiment, the present invention a plurality of copies of a recordable computer 
readable media having a tamper resistant software program thereon, comprising a first watermark 
installed in a first copy of a software program recorded on a first copy of a recordable computer 
readable media; a second watermark installed in a second copy of the software program recorded 

10 on a second copy of the recordable computer readable media; a watermark guard installed in the 
first copy of the software program, the watermark guard comprising at least one program 
instruction, the watermark guard being operable to verify the integrity of the first watermark; and 
the watermark guard installed in the second copy of the software program, the watermark guard 
being operable to verify the integrity of the second watermark, wherein the watermark guard is 

15 installed in the same location in the second copy of the software program as in the first copy of 
the software program. 

Li an embodiment, the present invention a plurality of copies of a recordable computer 
readable media having a tamper resistant software program thereon, comprising two or more 
program parameters installed in a first copy of a software program recorded on a first copy of a 
20 recordable computer readable media; a first value installed in the first copy of the software 
program, the first value comprising the two or more program parameters; two or more program 
parameters installed in a second copy of the software program recorded on a second copy of the 
recordable computer readable media; a second value installed in the second copy of the software 
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program, the second value comprising the two or more program parameters; a program parameter 
guard installed in the first copy of a software program, the program parameter guard comprising 
at least one program instruction, the program parameter guard being operable to verify the 
integrity of the first value; and the program parameter guard installed in the second copy of the 

5 software program, the program parameter guard being operable to verify the integrity of the 
second value, wherein the program parameter guard installed in the same location in, the second 
copy of the software program as in the first copy of the software program, 

In an embodiment, the present invention comprises a recordable computer readable media 
having a tamper resistant software program recorded thereon, comprising a first code block in a 

10 software program; a second code block in the software program, the second code block 
comprising a disguised copy of the first code block; and at least one repair guard installed in the 
software program, at least one of the at least one repair guards comprising one or more program 
instructions operable when executed to automatically undisguised the second code block and 
overwrite the first code block with the undisguised second code block. 

15 In an embodiment, the present invention comprises a recordable computer readable media 

having a tamper resistant software program recorded thereon, comprising a plurality of guards, 
each of the plurality of guards comprising at least one guard program instruction; and guard 
selection program instructions, the guard selection program instructions being operable to alter 
the control flow of the software program. In an aspect of this embodiment, the guard selection 

20 program instructions are operable to alter the control flow of the software program by causing the 
execution of one or more of the guard program instructions to be skipped. In an aspect of this 
embodiment, the guard selection program instructions are operable to alter the control flow of the 
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software program by causing the execution of at least one of the one or more of the guard 
program instructions that otherwise would be skipped. 

hi an embodiment, the present invention comprises a method for adding tamper resistance 
to a software program, the software program comprising a first software program variable and a 

5 second software program variable, wherein the first software program variable does not depend 
on the second software program variable, the method comprising the step of installing at least 
one guard in the software program, the at least one guard linking the first software program 
variable and the second software program variable so that an unauthorized change to the first 
software program variable changes the second software program variable. 

10 Li an embodiment, the present invention comprises a method for adding tamper resistance 

to a software program, the software program comprising a first code block and a second code 
block, wherein the first code block fiinctions independently of the second code block, the method 
comprising the step of installing at least one guard in the software program, the at least one guard 
causing fimctioning of the second code block to depend on proper fianctioning of the first code 

15 block so that an unauthorized change to the first code block changes the functioning of the 
second code block. 

hi an embodiment, the present invention comprises a recordable computer readable media 
having a computer program for adding tamper resistant features to a software program recorded 
thereon, comprising program instructions operable to install a plurality of guards in the software 
20 program, each of the plurality of guards comprising at least one guard program instruction, 
wherein each of the plurality of guards is operable to verify the integrity of at least one guard 
program instruction of at least one other of the plurality of guards, and wherein the integrity of at 
least one guard program instruction of each of the plurality of guards is verified by at least one 
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other of the plurality of guards; and program instructions operable to generate an executable 
version of the software program having the plurality of guards installed therein. 

In an embodiment, the present invention comprises a recordable computer readable media 
having a computer program for adding tamper resistant features to a software program recorded 
5 thereon, comprising program instructions operable to install a first watermark in a first copy of a 
software program; program instructions operable to install a second watermark in a second copy 
of a software program; program instructions operable to install a watermark guard in the first 
copy of a software program, the watermark guard comprising at least one guard program 
instruction, the watermark guard being operable to verify the integrity of the first watermark; and 

10 program instructions operable to install the watermark guard in the second copy of the software 
program, the watermark guard being operable to verify the integrity of the second watermark. 

In an embodiment, the present invention comprises a recordable computer readable media 
having a coniputer program for adding tamper resistant features to a software program recorded 
thereon, comprising program instructions operable to install two or more program parameters in 

15 a first copy of a software program; program instructions operable to generate a first value 
comprising the two or more program parameters installed in the first copy of the software 
program, the first value being likely to change if one or more of the program parameters installed 
in the first copy of the software program is changed; program instructions operable to store the 
first value in the first copy of the software program; program instructions operable to install two 

20 or more program parameters in a second copy of a soflAvare program; program instructions 
operable to generate a second value comprising the two or more program parameters installed in 
the second copy of the software program, the second value being likely to change if one or more 
of the program parameters installed in the second copy of the software program is changed; 
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program instructions operable to store the second value in the second copy of the software 
program; program instructions operable to install a program parameter guard in the first copy of a 
software program, the program parameter guard comprising at least one guard program 
instruction, the program parameter guard being operable to verify the integrity of the first value; 
and program instructions operable to install the program parameter guard in the second copy of 
the software program, the program parameter guard being operable to verify the integrity of the 
second value, wherein the program parameter guard is installed in the same location in the 
second copy of the software program as in the first copy of the software program, 

hi an embodiment, the present invention comprises a recordable computer readable media 
having a computer program for adding tamper resistant features to a software program recorded 
thereon, comprising program instructions operable to identify a first code block in a software 
program; program instructions operable to create a second code block, the second code block 
comprising a copy of the first code block; program instructions operable to disguise the second 
code block; and program instructions operable to install at least one repair guard in the software 
program, each of the at least one repair guards comprising at least one guard program instruction. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The features and advantages of this invention, and the manner of attaining them, will be 
more apparent and better understood by reference to the following descriptions of embodiments 
of the invention, taken in conjunction with the accompanying drawings, wherein: 

FIG. 1 A shows a flow chart illustrating a process for installing a repair guard according to 
the present invention. 

I' 
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FIG. IB shows a flow chart illustrating the operation of an embodiment of a repair guard 
according to the present invention. 

FIG. 2A shows software pseudocode in operation without a guard, and then with a simple 
guard according to the present invention. 
5 FIG. 2B shows the first and second computational component of a checksumming guard 

according to the present invention. 

FIG. 3 shows two examples of checksumming templates according to the present 
invention. 

FIG. 4 shows an example of expression rewriting to incorporate conditional identities 
10 according to the present invention. 

FIG. 5 shows a sample control flow graph of an application software program protected 
by a distributed network of three guards according to the present invention. 

FIGS. 6A-B show an example of assembly language code which computes and prints the 
factorial of a positive integer. 
15 FIGS. 7A-B shows the assembly language code of FIGS. 6A-B with a checksumming 

guard installed according to the present invention at the site identified in FIGS. 7A-B. 

FIG. 8 shows a graphical representation of two client code block protection schemes 
according to the present invention, wherein the same underlying client code block is protected by 
a first and a second protection layer of guards, each protection layer comprised of a different 
20 network of guards. 

FIG. 9A shows a diagrammatic example of guarding network according to the present 
invention. 
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FIG. 9B shows a diagrammatic example of a cyclic guard formation according to the 
present invention. 

FIG. 9C shows a diagrammatic example of a polycyclic guard formation according to the 
present invention. 

5 FIG. 9D shows a diagrammatic example of a dynamically determined guard formation 

according to the present invention. 

FIG. 9E shows a diagrammatic example of a dynamically determined guard formation 
according to the present invention. 

FIG. 9F shows a diagrammatic example of a dynamically determined guard formation 
10 according to the present invention. 

FIG. 9G shows a diagrammatic example of a network of guards according to the present 
invention. 

FIG. 9H shows a diagrammatic example of a partial guard graph showing the dominance 
relationship in the network of guards of FIG. 9G. 
15 FIG. 91 shows a diagrammatic example of scenarios in which a network of guards can be 

installed into the execution flow of a software program without violating the partial ordering of 
their executions shown in FIG. 9H. 

FIG. 10 shows a flowchart illustrating an embodiment of the assembly language code 
disguise process according to the present invention. 
20 FIG. 1 1 shows the merging process of two unrelated flows in a simple CFG according to 

the present invention. 

FIG. 12 shows two basic blocks being merged according to the present invention. 
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FIGS. 13A-B shows the sample assembly language code of FIGS. 6A-B after its code has 
completed the first phase of code merging according to CFG merging assembly language 
software code disguising technique of the present invention. 

FIGS. 14A-C shows the sample assembly language code from FIGS. 13A-B after the 
5 second phase of code merging according to the CFG merging assembly language software code 
disguising technique of the present invention. 

FIG. 15 shows a diagrammatic example of a control flow graph with its central portion 
disguised as a result of intensive merging according to the present invention. 

FIG. 16 shows a diagrammatic example of a single link-node contained in a basic block 
10 of an original CFG according to the present invention. 

FIG. 17 shows a diagrammatic example a process of preserving link-nodes in the new 
basic block created from CFG merging according to the present invention. 

FIG. 18 shows a diagrammatic example of network of dynamically changing and 
mutually dependent data values resulting from the data precomputation method of the present 
15 invention. 

FIGS. 19A-B show an algorithm for performing data precomputation according to the 
present invention. 

FIG. 20 shows a diagrammatic example of data precomputation based on an underlying 
graph of link-nodes according to the present invention. 
20 FIG. 21 shows a diagrammatic example of a CFG-cloning assembly language code 

disguising technique according to the present invention, wherein basic block t has been cloned 
from basic block x in FIG. 1 1, so that the flow coming from D' can go through either of jc or / in a 
randomized manner. 
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FIG. 22 shows an example of a randomized jump-based decision based on two variables 
after the process of CFG cloning according to the present invention has been performed. 

FIG. 23 shows a diagrammatic example of data-aliasing according to the present 
invention, wherein the two occurrences of variable t are aliased by variables ti and t2, which are 
5 pointers containing the partial address of t. 

FIG. 24 shows the process of encoding a watermark message into a sequence of byte 
strings according to the present invention. 

FIG. 25 shows a diagrammatic example of a clone attack. 

FIG. 26 shows one embodiment of a method of installing SPC according to the present 
10 invention. 

FIG. 27 . shows a table illustrating several examples according to the present invention 
where high-level semantics shown in the left column of the table are replaced by groups of 
simpler instructions with the same semantics shown in the right column. 

FIG. 28 shows a conceptual diagram illustrating the attachment of a digital signature and 
15 encrypted customization parameters to the end of an application software program file according 
to the present invention. 

FIG. 29 shows a table illustrating the actions of a self-protecting software program of the 
present invention which produces incorrect results whenever its code is altered, even on inserting 
a single null instruction into the code. 
20 FIG. 30 shows a block diagram illustrating the operation of one embodiment of a system 

for creating a tamper resistant application software program according to the present invention. 
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DESCRIPTION 

The present invention comprises a software-only method for solving the problem of 
unauthorized modification of software program code, and a system for practicing the method. 
The method utilizes self-protecting code, whereby the protected application software programs 
5 are armed with intemal self-protection mechanisms that may render the application software 
program unusable if a predetermined portion of the appUcation software program code is 
tampered with. The present invention may utilize, but does not require, cryptographic 
techniques. Li an embodiment, the operation of the system of the present invention is automatic. 
In an embodiment of the present invention, an "application software program" is one that 

10 is executed by an operating system, and is portable in the sense that source code for an 
application software program may be compiled by techniques well known in the art into one of 
many different assembly languages for use with one of many different microprocessors and one 
of many different operating systems. An application software program may be multi-threaded. 
In an embodiment, the present invention is adapted to guard an application software program 

15 comprising an operating system program. 

As used in the specification and the claims, a "guard" is a portion of software code of an 
application software program that makes the software code of the application software program 
less susceptible to tampering. A guard comprises at least one program instruction. A program 
instruction comprises at least one byte sequence. 

20 A "code block" of an apphcation software program is a portion of the application 

software program containing any byte sequence, but is less than the entire application sofl:ware 
program. The same byte sequence may comprise one or more code blocks of an application 
software program. Often, a code block to be protected by a guard, called a "client code block," 
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may be an entire function or named procedure, although a client code block could be smaller than 
a single instruction. A guard may have more than one client code block. 

Li a first embodiment, a guard according to the present invention comprises a "repair 
guard." A repair guard is operable to repair application software program code at run-time. A 
5 repair guard according to the present invention may be implemented according to one of two 
embodiments, hi a first embodiment, a predetermined segment of application software program 
code is intentionally damaged. The first embodiment of the repair guard is operable to overwrite 
the damaged code at run-time. If the repair guard is defeated, the intentionally damaged code 
remains in the application software program. Thus, the application software program will not 

10 operate correctly. 

hi a second embodiment of a repair guard according to the present invention, the 
application software program code is not intentionally damaged. Instead, vulnerable portions of 
the application software program are identified. It is anticipated that a hacker may try to alter the 
vulnerable portions of the application software program code. The repair guard is operable to 

15 overwrite these vulnerable portions of the application software program code at run-time. 
Accordingly, the hacker's efforts are frustrated when the altered portions of the application 
software program code is overwritten by the repair guard. 

Referring now to FIG. 1 A, there is shown a flow chart illustrating a process for installing 
a repair guard according to the present invention. Beginning with a working application software 

20 program, in the step shown as block 111 of FIG. lA program instructions comprising a repair 
guard are installed in the application software program. Next, in the step shown as block 1 12 of 
FIG. 1 A, a client code block for the repair guard is identified. The client code block of a repair 
guard according to the present invention comprises one or more program instructions of the 
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application software program. In the step shown as block 113 of FIG. 1 A, a random number R is 
identified. Next, in the step shown as block 114 of FIG. lA, a copy of the repair guard's client 
code block is made. In the step shown as block 115 of FIG. lA, the client code block copy 
(called a "repair code block") is disguised. In one embodiment of a repair guard according to the 
5 present invention, the repair code block is disguised by performing a bitwise XOR operation 
between the repair code block and random number R. In other embodiments the repair code 
block may be disguised by encryption or by another technique that can later be reversed to 
undisguise the repair code block, as discussed hereinafter. Next, in the step shown as block 116 
of FIG. lA, the disguised repair code block is stored in the application software program. In one 

10 embodiment of a repair guard according to the present invention, the disguised repair code block 
is stored such that at run-time it appears to be program data for the application software program. 
Finally, in the step shown as block 117 of FIG. lA, the original client code block remaining in 
the application software program is intentionally damaged. Preferably, the chent code block is 
damaged to the extent that the application software program is inoperable unless the code is 

15 repaired. 

The following shows exemplary assembly language code of a sample repair guard that, 
when executed, repairs its client code block located at memory range [clientAddr, 
clientAddr+clientLen] to its original form. The repair code block has been disguised by an XOR 
operation and is stored in the memory area designated as "copy." As discussed hereinafter 
20 certain parameters in a guard template (such as the ''clientAddr,'' "clientLen," and "mask" shown 
in this example) are initialized to predetermined values when the guard is instantiated. Thus, the 
same guard template can be parameterized differently for different guard instantiations. The 
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code below is written in a publicly available NASM (Netwide Assembler) syntax for Intel 32-bit 
architectures. 



Sample repair guard: 



BITS 32 
SECTION .text 

Extern clientAddr, clientLen, mask 



for (ebx = 0 to clientLen-4 step 4) 

*(clientAddr+ebx) == *(copy-i-ebx) xor mask 



guard: 



push 
push 
mov 



eax 
ebx 
ebx,0 



LI: 



cmp ebx, clientLen - 4 

jg end 

mov eax, dword[copy+ebx] 

xor eax, mask ; unmask the masked copy 

mov [client Addr+ebx], eax 

lea ebx, [ebx+4] 

jmp LI 



pop ebx 
pop eax 

SECTION .data 
copy resb 1 00 ; stores the masked copy of client code 

Referring now to FIG. IB, there is shown a flow chart illustrating the operation of an 
implementation of the first embodiment of a repair guard according to the present invention. In 
the step shown as block 121 of FIG. IB, execution of the appUcation software program begins. 
Next, in the step shown as block 122, the damaged cUent code block is loaded into computer 



end: 



memory. 
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Program execution continues until, in the step shown as block 123 of FIG. IB, the 
program instructions comprising the repair guard are executed. During execution of the repair 
guard's program instructions, the disguised repair code block is retrieved. Then, the disguised 
repair code block is undisguised in this embodiment of the present invention by performing a 
5 bitwise XOR operation with the repair code block and random number R. It is known that 
performing a bitwise XOR operation between two instances of the same vector results in a vector 
of all zeroes. Likewise, performing a bitwise XOR operation between a vector of all zeroes and 
any other vector V results in vector V. Accordingly, because the repair code block was disguised 
using a bitwise XOR operation between the repair code block and random number R, a second 
10 bitwise XOR operation "cancels" the random number R and reveals the repair code block. If 
encryption or another disguise technique was used in disguising the repair code block, the repair 
code block is undisguised in this step by applying the reverse of that disguise technique (e.g., 
decryption). 

Next, in the step shown as block 124 of FIG. IB, the damaged client code block is 
15 overwritten in computer memory by the undisguised repair code block. Finally, in the step 
shown as block 125, execution of the application software program proceeds using the 
undisguised repair code block. 

The operation of the second embodiment of a repair guard according to the present 
invention is substantially the same as the flow chart shown in FIG. IB. The difference between 
20 the operation of the first and the second embodiments is that the client code block in the second 
embodiment is not necessarily damaged before it is^overwritten. 
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An extreme form of a repair guard is a guard called a "code-writing" guard. A code- 
writing guard according to the present invention rewrites large fragments of the application 
software program a^ run-time. 

A second embodiment of a guard according to the present invention comprises a "silent 
guard." A silent guard according to the present invention comprises a portion of software code of 
an application software program that evaluates the integrity of one or more data items, and takes 
a predetermined and possibly delayed action inconsistent with the proper execution of the 
application software program (a "defensive action") if the silent guard detects a deficiency in the 
integrity of the evaluated data item(s). 

hi an embodiment, a silent guard may operate to initialize a variable to a desired value 
before the variable is used in a computation. Absent proper execution of the silent guard, the 
variable may not have the appropriate value when it is used in the computation, possibly causing 
the application software program to perform inaccurately or to fail. 

In another embodiment, a silent guard according to the present invention comprises a 
variable whose value is computed during execution of the application software program. 
Typically, the variable selected for silent guarding is a program variable used by the application 
software program to carry out its intended fiinction. However, the variable selected for silent 
guarding may be a specialized variable installed in the application software program for the 
purpose of the silent guard. A variable may be selected for silent guarding because the value of 
the variable is vulnerable to attack or modification by a hacker, An attack on or unauthorized 
modification of such a variable results in detrimental effects to program execution. For example, 
a variable whose value comprises a password entered by a user of the application software 
program may be selected for silent guarding. If such a variable is unauthorizedly modified, a 



P00620-US-01 



hacker may gain access to an application software program to which he otherwise would not be 
entitled. 

According to an embodiment of a silent guard, the variable selected for silent guarding 
has an expected value, i.e., the value the variable should have at a particular point in program 

5 execution. In an embodiment, the expected value may be determined by an adaptation of the 
method for data precomputation discussed hereinafter, or by other methods known in the art. Li 
an embodiment, a silent guard comprises a comparison of the run-time value of the variable 
selected for silent guarding against its expected value. If the comparison reveals that the run- 
time value of the variable is the same as its expected value, application software program 

10 execution proceeds as expected. A defensive action results if the comparison reveals a difference 
between the run-time value of the variable selected for silent guarding and its expected value. 

The run-time value of a variable selected for silent guarding may change one or more 
times during execution of the application software program. For example, the run-time value 
assigned to the variable as a result of a first computation may be overwritten by a second 

15 computation, and then overwritten again by a third computation. A silent guard according to the 
present invention is adaptable for this circumstance. The expected value of the variable selected 
for silent guarding is its expected value at the point in the execution of the application software 
program where the comparison is made. Thus, the same variable may be protected by a silent 
guard more than once in an application software program. 

20 In an embodiment of a silent guard according to the present invention, the comparison of 

the run-time value of the variable selected for silent guarding against its expected value 
comprises a conditional computation. According to this embodiment, one or more mathematical 
expressions comprising the comparison of the run-time value of the variable seleicted for silent 
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guarding against its expected value are inserted into one or more program instructions from the 
application software program such that correct execution of the one or more application software 
program instructions depends upon the run-time value of the variable selected for silent guarding 
being the same as its expected value. 

In an embodiment, the comparison using the run-time value of the variable selected for 
silent guarding may be indirect, hi this embodiment, the run-time value of the variable selected 
for silent guarding is processed at run-time by an algorithm. The expected value of the variable 
also is processed by the algorithm, either concurrently or beforehand. In this embodiment, the 
algorithm's output using the run-time value of the variable is compared to the algorithm's output 
using the expected value of the variable. A defensive action results if the comparison reveals a 
difference therebetween. As before, the comparison may be embodied in one or more 
mathematical expressions inserted into one or more program instructions from the application 
software program, so that correct execution of the one or more application software program 
instructions will depend upon the run-time value of the variable selected for silent guarding being 
the same as its expected value. 

The following pseudocode segment contains an exemplary implementation of a silent 
guard. In this example, variable X has an expected value "TRUE." The label "L" indicates the 
point in the application software program where execution of the non-guard program instructions 
is resumed. The pseudocode is of the form: 

Compute X 

If(X = TRUE)gotoL 

Take Defensive Action 
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L: Resume execution of non-guard program instructions 

According to this pseudocode segment, the application software program first computes 
the value of variable X. Then the computed value of variable X is compared to its expected 
5 value "TRUE." If the computed value of variable X is equal to "TRUE," program execution 
advances to the point in the application software program corresponding to the label "L," where 
execution of the non-guard program instructions is resumed. If the computed value of variable X 
is not equal to "TRUE," the silent guard takes a defensive action. Note that in this example, it is 
not important that the expected value of X is the Boolean value "TRUE." The expected value of 

10 X could have been any number (integer or real), any_character string, or a Boolean value. It 
should also be noted that, although the foregoing example and other examples used herein to 
explain the operation of silent guards use an "if-then-else" formulation, that represents merely 
one possible implementation of a silent guard. In most applications, a silent guard will be 
installed such that its operation is more implicit. 

15 The following pseudocode segment illustrates the use of a conditional computation 

according to the present invention. In the pseudocode segment of the following example, 
variable V is a program variable used in the application software program. As in a previous 
example, the silent guard comprises a variable X whose expected value is "TRUE." Also shown 
is a second variable XI whose value is computed during the computation of variable X. Variable 

20 XI has an expected value Tl. This example also comprises a flag variable F. The value of flag 
variable F is initialized to 0, and is changed to 1 after the silent guard program instructions are 
executed. Line numbers are shown in the following example to assist in the explanation; 
however, the use of line numbers in this example and other examples herein does not necessarily 
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mean that actual program code based on these pseudocode instructions will consist of only the 
number of lines shown in the example. It will be appreciated by those of skill in the art that other 
program instructions may be interspersed between pseudocode program instructions shown 
below to be adjacent without affecting the output of the pseudocode segment. For example, the 
pseudocode program instruction of line 7 below (identified by label "L") need not be located 
immediately after the pseudocode program instruction of line 6. Likewise, any of the other 
pseudocode program instructions shown below to be adjacent may, when implemented as 
program instructions in a programming language, be separated by one or more other program 
instructions. 



1 F = 0 

2 Compute XI 

3 Compute X 

4 . F- 1 

5 If(X = TRUE)GoToL 

6 Take Defensive Action 

7 L If(F = 0)GoToLl 

8 V = Z * (A*Z + B) + 72 //sample computation of V 

9 Y1=X1-T1 

10 V = V+Y1 

11 LI Continue 
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In this example, the application software program is protected in three ways. First, if the 
value of variable X computed at line 3 does not equal TRUE in the comparison step at line 5, the 
program will take a defensive action, as shown at line 6. 

Second, flag variable F acts as a silent guard. If the application software program is 
5 altered in a way such that the value of flag variable F is not set to 1 in the pseudocode program 
instruction shown at line 4, the computation of V shown at line 9 will be skipped. For example, 
if the control flow of the application software program is altered unexpectedly (such as by the 
actions of a hacker attempting to defeat a guard) in way that bypasses the execution of the 
pseudocode program instruction shown at line 4, the value of flag variable F remains 0. When 

10 the program instruction shown at line 7 is processed, execution of the application software 
program advances to line 11, bypassing the program instructions shown at lines 8-10. Thus, 
calculation of the value of program variable V is skipped. Program variable V retains whatever 
value it had prior to execution of this section of the application software prograni. If program 
variable V is to be used later in the application software program, computations relying on 

15 program variable V likely will be inaccurate. If program variable V is used fi^equently in the 
application software program, the inaccurate value of program variable V may propagate into 
many errors in the application software program. Conversely, if program variable V is used 
infrequently in the application software program, the inaccurate value of program variable V may 
not manifest into a discemable error until much later in program execution. In either case, it may 

20 be difficult to detect the source of the program execution errors. 

The third protection contained in the foregoing pseudocode example arises from the fact 
that the value of program variable V computed at line 10 will be correct only if the value of Yl is 
0. Thus, the pseudocode program instruction "Yl=Xl-Tr' shown at line 9 comprises a 



P00620-US-01 



conditional computation according to the present invention. The value of Yl will be computed 
correctly only if the value of variable XI computed at hne 2 is the same as its expected value Tl. 
Accordingly, if the client code block of variable XI is altered unexpectedly, such as by the 
actions of a hacker, the value of computed variable XI will not be the same as its expected value 

5 Tl. If XI 9^ Tl, the value of variable Yl computed at line 9 will be inaccurate and, thus, program 
variable V will be inaccurately computed at line 10. As before, depending on where and how 
program variable V is used in the application software program, the inaccurately computed value 
of program variable V may not become manifest until later in program execution. A hacker 
altering the computation of variable XI may have difficulty connecting the altered computation 

10 of variable XI with the failure caused by the inaccurately computed program variable V, 

A third embodiment of a guard according to the present invention comprises a 
"checksumming guard." A checksumming guard according to the present invention comprises a 
portion of software code of an application software program that evaluates the integrity of one or 
more code blocks of the same application software program, or of another guard, and takes a 

15 defensive action if the checksumming guard detects a deficiency in the integrity of the evaluated 
code block(s) of the application software program. A checksumming guard differs from a silent 
guard in that a silent guard evaluates the integrity of one or more data items, while a 
checksumming guard evaluates the integrity of one or more code blocks. 

A defensive action taken by a checksumming guard could be to hah program execution or 

20 to cause a message to be sent to the user's computer terminal or printer, but such a defensive 
action taken immediately upon the detection of the integrity deficiency could be undesirable 
because it could assist a hacker in determining the location of the checksumming guard and 
disabling the checksumming guard within the application software program. In one embodiment 
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of the present invention, the defensive action is to modify the contents of all or a portion of the 
data upon which the application software program operates. Accordingly, as the application 
software program continues to execute, the modified data likely will cause other noticeable 
errors, and it will be more difficult for a hacker to determine when and where the data was 
5 modified. Alternatively, the defensive action could be to overwrite the contents of a portion of 
the executable program instructions in computer memory. Any modification could be done with 
pre-determined data or data randomly and automatically generated by the checksumming guard. 
Data areas to be modified could be specified in advance by the person creating the tamper- 
resistant software, or preferably could be selected randomly and automatically by the present 

10 invention. In another embodiment of the present invention, the defensive action is to cause a 
message to be stored in computer memory for future use by the application software program. 

Li an embodiment of the present invention, a checksumming guard uses one or more 
checksums to verify the integrity of one or more client code blocks. A "checksum" is a value 
calculated from one or more client code blocks that is Ukely to change if such code block(s) 

15 is/are modified. It is preferred (but not required) that a checksumming function according to the 
present invention uses a "one-way" function which, according to this embodiment, can be any 
function whereby the checksum of a client code block is computed in a manner that makes it is 
impossible thereafter to derive the cUent code block from the value of the checksum, or that 
makes it impossible thereafter to derive another client code block that results in the same 

20 checksum as the original client code block. For example, a checksum of a client code block may 
be computed by squaring a preliminary checksum, and then calculating its modulo w, where n is 
. the product of two secret prime numbers. The checksum value is the value of the squared 
preliminary checksum modulo n and is stored in the application software program. The attacker 
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thereafter cannot compute square root of the squared preUminary checksum modulo n without 
knowing the two secret prime numbers. Other examples of one-way functions include a 
cryptographic, one-way hash function and the well known MD4, MD5, and Sha-1 algorithms, as 
well as other one-way functions as would occur to those of ordinary skill in the art. 

5 Normally, checksumming guards will be designated to protect code blocks of an 

application software program in which particularly sensitive data is processed, such as encryption 
or decryption routines (if any), processing of passwords used by the apphcation software 
program, or where important calculations are made. Optionally, a checksumming guard may 
contain, between its beginning and ending program instructions, other program instructions from 

10 the original application program, so that the checksumming guard code and the original code are 
interleaved. 

A client code block to be monitored by a checksumming guard may include only static 
byte sequences that do not change during program execution, or may include self-modifying code 
or self-decrypting code. If the client code block includes self-modifying code or self-decrypting 

15 code, it is essential that the self-modifying code or self-decrypting code be in the state of self- 
modification or self-decryption expected by the checksumming guard at the point of program 
execution where integrity of the client code block is verified by the checksumming guard. If the 
self-modifying code or self-decrypting code is not in the expected state, the checksumming guard 
may erroneously take a defensive action. 

20 FIG. 2A shows software pseudocode in operation without a guard, and then with a simple 

checksumming guard example of the present invention. The pseudocode in part (a) of FIG. 1 . 
having no guard has been transformed to the pseudocode in part (b) of FIG. 2A through the 
installation of a checksumming guard. Both part (a) and part (b) are functionally equivalent, 
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except that the checksumming guard in part (b) of FIG. 2A protects the jump instruction (the 
client code block) from being modified, provided that mem [client] contains the whole jump 
instruction. In part (b) of FIG. 2 A, k has the value of memfclientj - 1, and the code increments 
mem[%rj correctly if and only if the jump instruction is intact. If the jump instruction is not 
5 intact, the defensive action taken is that mem [%r] is not correctly incremented. 

Guards may be installed into application software programs, such as those written in a 
high level programming language such as C, C++, Pascal, or Fortran, or those written in the 
assembly language of any computer hardware architecture known in the art, or those written in 
binary executable form or object code form. Because they are not restricted to high-level 

10 application software program syntax and control structures, instruction-level primitives allow 
assembly language code to be flexibly transformed to an appropriate state for self-protection. 
Assembly language code compiled from code written in one of the high-level software 
programming languages well known in the art, such as, for example, code written in C, C++, 
Pascal, or Fortran, or compiled Java bytecode, may be used as application sofl^vare program 

15 code. Assembly language code fi-om other sources may be used as the application software 
program code, provided the assembly language code is an assembly language code that does not 
base its computations on fixed absolute addresses. Generally, binary executable code or object 
code may be used as application software program code provided the binary executable code or 
the object code does not base its computations on fixed absolute addresses. However, if the 

20 binary executable code or the object code bases its computations on fixed absolute addresses, the 
binary executable code or the object code still may be used as application software program code 
if the binary executable code or the object code is converted to a form in which the dependence 
on the use of fixed absolute addresses is eliminated. The vast majority of commercial software 
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development results in assembly language code which can serve as application software program 
code for the present invention. 

hi addition to the installation of guards, the present invention permits a set of messages of 
virtually any size to be embedded into the guarded application software program as one or more 

5 data strings, which may be encrypted using encryption techniques known in the art, or disguised 
as programming instructions using encoding techniques known in the art. Such a message is 
known as a software "watermark" or "fingerprint." These optional watermarks or fingerprints 
often contain information about the vendor or the proper licensee of the application software 
program. It is desired that watermarks or fingerprints be tamper resistant, a characteristic called 

10 "resilience." Watermark or fingerprint resilience may be enhanced by encryption of the 
watermark or fingerprint, or by disguising the watermark or fingerprint as application software 
program instructions using well known encoding techniques, hi addition to or instead of the 
aforementioned techniques, the present invention may improve watermark or fingerprint 
resilience by hiding the watermarks or fingerprints in the code and protecting the watermarks or 

15 fingerprints by the same self-protection mechanisms that protect the application software 
program. Thus, attempts to alter a watermark such as, for example, altering the vendor or 
licensee information, will trigger a guard and may disable the use of the application software 
program. Such tamper-resistant watermarks or fingerprints are useful for tracing copyright 
violators who illegally alter or redistribute application software programs. 

20 The present invention permits the user to specify parameters for customizing the guard 

installation process. One example of a guard installation customization parameter is the number 
of guards to be installed into an application software program. The user may specify the number 
of guards to be installed. Altematively, the user may permit the present invention to specify 
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automatically the number of guards to be installed. For example, the present invention may 
specify automatically the number of guards to be installed by randomization, or may specify 
automatically the number of guards to be installed based on a measurement of the complexity of 
the application software program using a software complexity metric known in the art. In 
another embodiment, the present invention may specify automatically the number of guards to be 
installed based on an analysis of the application software program, its intended use, and/or its 
intended environment. For example, if the application software program contains valuable trade 
secrets, if the application software program is to be used to process classified information, if high 
reliability is required from the apphcation software program, and/or if the environment in which 
the application software program is to be used is such that tampering is likely, the application 
software program would be protected automatically with more guards than an application 
software program which does not possess such features and/or is not exposed to such threats. 

Another example of a guard installation customization parameter involves the use of a 
random number generator seed. The seed will drive a random number generator to produce a 
randomized sequence of numbers, which in turn will be used to achieve randomization across 
protection schemes or within the same protection scheme. The end result is that even if the same 
copies of an application software program are protected with the same self-protection scheme, 
their actual protections will be different, as if they were protected with different schemes. 
Randomization in application software program protection is particularly effective in thwarting 
attacks against a widely distributed application software program, such as a word processing 
application software program for use in a home or office environment. The random nature of the 
application software program protection precludes the same tampering method from being 
applied to differently protected copies of an application software program. 
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Another advantage of the method of the present invention is that the user may Hnk 
external object files or library resources with the self-protecting application software program. 

The output of the method of the present invention is a binary executable version of the 
application software program, internally armed with at least one guard and optionally embedded 
5 with guarded watermarks. 

FIG. 2B shows a first and a second computational component of an embodiment of a 
checksumming guard according to the present invention. Together, the first and second 
computational components are called a "checksumming guard template." The checksumming 
guard template is converted into a checksumming guard during generation of the final binary 
10 executable file. The first computational component computes one or more checksums of the 
client code block(s). The second computational component performs "conditional computations" 
for the host during program execution in which the checksum of one or more client code blocks 
are compared to known or derived values. When the checksum matches the known or derived 
value, the checksumming guard permits normal host software computations to proceed. When 
15 the checksum differs from the known or derived value, the checksumming guard will "fire," 
resulting in possibly delayed defensive action fi'om the application software program. 

The first computational component of a checksumming guard is based on a predefined 
checksumming template. The second computational component of a checksumming guard has 
no predefined structure. Its structure depends on the application software program. 
20 The first computational component of a checksumming guard is constructed fi-om at least 

one predefined checksumming template that specifies checksum computations. There are many 
possible forms of such templates. In one embodiment of the present invention, the 
checksumming templates are provided for the user by the present invention, giving the user the 
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ability to select a desired checksumming template(s) to use by name or other identifying 
characteristic. In another embodiment of the present invention, the user may develop customized 
checksumming templates for his own use without relying on the present invention to provide 
checksumming templates. Another embodiment of the present invention combines the features 

5 of these embodiments, providing the user with a set of checksumming templates which may be 
selected by name or other identifying characteristic, while also providing the user the ability to 
develop customized checksumming templates for his own use. FIG. 3 shows two examples of 
checksumming templates according to the present invention written in INTEL®-like assembly 
language code instructions. 

10 The first checksumming template example illustrated in FIG. 3, template 1, describes a 

simple checksum computation, which produces a single checksum of its client code block. The 
second checksumming template example illustrated in FIG. 3, template 2, produces two 
checksums based on different operations. In each of template 1 and template 2, there are special 
parameters such as CHECKSUM *, $START_*, and $END_* that denote checksum variables 

15 and the starting and ending segment addresses of the client code block, respectively. These 
parameters, as well as others, such as LABEL_* and TEMP_*, will be mapped to their 
corresponding host variables or values in the process of checksumming guard installation. Note 
that the checksumming templates also contain random-valued parameters $RANDOM * which 
are randomly initialized during the checksumming guard installation. These random-valued 

20 parameters can be made to adjust the rigor of checksumming, even for simple checksumming 
schemes. For example, the smaller the initialized values of $RAND0M 2 in each of template 1 
and template 2, the more sensitive the checksumming schemes in each. 
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It is preferable that the first computational component of a checksumming guard not be 
made too complicated, because simpler checksumming guards are more likely to remain 
undetected by a hacker in the application software program than are complex checksumming 
guards. Furthermore, the strength of the application software program protection preferably does 

5 not depend on a single checksumming guard at one location. Instead, it preferably depends on a 
distributed network of checksumming guards that collectively perform checksumming on the 
same or on different cUent code blocks. This technique is called "distributed checksumming." 

The number of different checksumming templates available to be used as the first 
computational component of a checksumming guard is not a critical factor. Code disguise 

10 transformations performed on the application software program after checksumming guard 
installation will disguise the code, hindering detection of recurring checksumming guard code by 
a hacker. The disguise transformation code inserted creates new protection capabilities that 
protect the both the checksumming guards and the application software program firom tampering. 
Prior to installing a checksumming guard, the user may specify to the system that creates 

15 the tamper resistant software how many checksumming guards to deploy within the application 
software program, which client code to protect, which of the plurality of available checksumming 
templates to use, and at which point(s) in the application software program code the 
checksumming guard is to be installed. Such specification may be made through a user interface 
means known in the art such as, for example, a graphical user interface. In one embodiment of 

20 the present invention, these factors may be selected randomly and automatically by the system 
that creates the tamper resistant software. After these decisions are made, the first step in the 
checksumming guard installation process is installing each checksumming template into the host. 
Parameters in the checksumming template are mapped to host variables or values, and the 



P00620-US-01 



42 



resulting code then is inserted at the chosen installation point. Checksum parameters may be 
mapped to new global variables. Other parameters such as client addresses, code labels, and 
temporary variables may be mapped to corresponding addresses, new labels, and unused registers 
(or to new global variables if all registers are live at the insertion point) in the appHcation 

5 software program, respectively. 

Following the installation of each checksumming template, the next step in the 
checksumming guard installation process is generating the second computational component of 
the checksumming guard, hi an embodiment, the second computational component contains one 
or more expressions from the application software program that have been modified by the 

10 insertion of one or more conditional identity functions such that correct execution of the one or 
more application software program expressions will depend upon the presence of one or more 
checksums computed by the first computational component of the checksumming guard which 
match predetermined values for, or derived from, the one or more checksums. 

First, at least one application software program expression to be modified by the insertion 

15 of one or more conditional identity functions must be selected. Optionally, the at least one 
application software program expression is selection by the user. An expression selected for 
modification must be at a location in the application software program execution flow such that 
upon reaching the expression during execution, the one or more checksum variables to be used in 
the modified expression always will contain checksums computed by the first computational 

20 component of the checksumming guards which have not been modified by apphcation software 
program execution subsequent to their computation One or more "conditional identities" formed 
by the checksum variables and their corresponding constant values are inserted into each selected 
expression. Conditional identities are any expressions that, using the available checksum 
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variables and corresponding constant values, conditionally compute "0" or "1" or another number 
or value as required to maintain computational accuracy of the application software program 
expression selected for modification. Conditional identities may be selected by the user, or 
generated randomly and automatically by the system that creates the tamper resistant software. 
Each expression then is rewritten to incorporate the one or more conditional identity functions 
concealing the real checksum values. The rewriting will appear to transform the real checksum 
values to other different numbers. The corresponding constant values with which the checksum 
variables form conditional identities are generated during the patching step of the present 
invention explained hereinafter. 

FIG. 4 shows an example of expression rewriting to incorporate conditional identities 
according to the present invention. In FIG. 4, expression (1) is transformed to expression (2) via 
a process of inserting into expression (1) mathematical identity elements (in this case O's) in such 
a way that the result is not affected. The identity elements are then replaced in expression (3) by 
appropriate expressions formed by pairs of computed checksum values (m and w) and their 
corresponding constant values (wo and wo) against which they will be verified. Expression (3) 
then is rearranged to hide the changes. The final result is expression (4), which is conditionally 
equivalent to expression (1). 

The next step in the checksumming guard installation process is to mark those data values 
derived from the checksum values. All checksum values are unknown to the system at this stage 
because they will be computed during the patching step of the present invention (discussed 
hereinafter) from the contents of an output binary image that has not yet been created. Therefore, 
any data values derived from such unknown sources must be recomputed and rewritten to the 
code once they become known during the patching step of the present invention. At this stage, 
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the system only marks the locations for all data values to be derived from unknown checksum 
values, and saves the sequences of operations that will derive the data values from the unknown 
checksums. 

Self-protection may be based on a distributed network of guards that protect the 
5 application software program and each other in a cooperative manner. FIG. 5 shows a sample 
control flow graph ("CFG") of an application software program protected by a distributed 
network of three guards according to the present invention. The three guards are shown in the 
darker circles, and labeled as guard 11, guard 12, and guard 13. Guard 11 is responsible for 
protecting its client code, shown as a shaded region and labeled as client code block 21. Guard 
10 12 is responsible for protecting its client code, shown as a shaded region and labeled as cUent 
code block 22. Guard 13 is responsible for protecting its client code, shown as a shaded region 
and labeled as client code block 23. 

Self-protection is reinforced by having guards protect each other. In FIG. 5, guard 11 
protects cUent code block 21, which contains guard 12, Also in FIG. 5, guard 12 protects cUent 
15 code block 22, which contains guard 13. The three guards form a protection chain, making the 
task of modifying the apphcation software program more difficult. For example, to defeat guard 
13 which protects the start of the application software program, guard 11 and checksumming 
guard 12 have to be defeated as well. 

Because guards may be installed almost anywhere in the code, and because guards can 
20 protect each other in many ways, defeating a self-protecting software program could require a 
laborious effort of wholesale "code debugging" — an effort that may become greater than that of 
rewriting the application software program from scratch. FIGS. 6A-B show an example.. of 

r 

assembly language code which computes and prints the factorial of a positive integer. FIGS. 7A- 
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B show thp assembly language code of FIGS. 6A-B with a checksumming guard installed 
according to the present invention at the site identified in FIG. 7 A at line 39. 

There are several additional advantages of a scheme employing protection by a 
distributed network of guards. For example, unlike the approach disclosed by Aucsmith in his 

5 article of using few security kernels to protect the application software program, with each 
security kernel requiring a large number of instructions for proper operation, distributed 
protection by a larger number of smaller checksumming guards requiring fewer instructions 
provides the following advantages: (a) checksumming client code block(s) by a distributed 
^ networks of checksumming guards may be simplified because the load is shared among the 

10 checksumming guards in the network; (b) a distributed networks of checksumming guards can be 
installed in a wide variety of logical formations to defend the client code block(s); and (c) due to 
the small size of the checksumming guards, each checksumming guard may be more easily 
concealed in the appUcation software program code to prevent discovery by a hacker. 

A protection scheme employing a distributed network of guards relies on a balance 

15 between the level of protection it offers and the amount of additional degradation to application 
software program performance the user will tolerate. Increasing the level of protection means 
more guards are used to protect more client code blocks. Each additional guard requires storage 
space and increases computational overhead on the application software program. A heavily 
protected application software program with a large number of guards may result in a substantial 

20 loss of computational speed. While the method of the present invention implements severa^l 
protection schemes and could select one or more client code blocks at random to be protected, it 
is preferable that the user of the present invention specify which portions of the software program 
. to protect and what level of protection is desired. 
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The client code blocks to be protected may be marked and labeled with the desired level 
of protection or specific protection scheme specified by the user. The user may do so, for 
example, through a graphical user interface that allows specific client code blocks to be 
designated, or by identifying the names of routines or basic blocks containing the client code 

5 blocks. Alternatively, at the option of the user, the client code blocks to be protected may be 
selected randomly and automatically. Other means of identifying the client code blocks known 
in the art may be utilized, such as identification of the client code blocks by name as an input 
parameter to a software program embodying the present invention. For high volume production 
of self-protecting software programs originating from the same software program source, such 

10 user-supplied information may be specified only once, and then replicated automatically. 

Each portion of the code to be protected then is identified at the basic block level so that 

V 

basic blocks are the smallest units of code to be protected. For additional security, the existing 
set of marked basic blocks may be extended to a larger set that contains all ancestor basic blocks 
of all paths of length "AT" or less that precede each originally marked basic block. This is to 

15 ensure *^code protection range" comprising the "neighborhood of radius TV" of each sensitive basic 
block is protected as well. The neighborhood of radius N of each originally marked basic block 
is protected in the same way as the basic block, and if a newly marked basic block has 
overlapped protection, it is given correspondingly larger protection. 

FIG. 8 shows a graphical representation of two client code block protection schemes 

20 according to the present invention, wherein the same underlying cUent code block is protected by 
a first and a second protection layer of guards, each protection layer comprised of a different 
network of guards. Part (a) of FIG. 8 illustrates as the bottom layer a client code block protected 
by a first and a second protection layer of guards, each protection layer comprised of a single 
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guard protecting the entire scope of the code block. Part (b) of FIG. 8 illustrates the same client 
code block protected by a first and a second protection layer of guards as in part (a), but each 
protection layer in part (b) is comprised of two different guards instead of a single guard. The 
different shades shown in part (a) and part (b) indicate the different guards using different 
5 ftinctions. For example, the client code blocks in FIG. 8 may be protected by checksumming 
guards, repair guards, or a combination of checksumming guards and repair guards. 

Each protection scheme illustrated in FIG. 8 has advantages and disadvantages. The 
scheme illustrated in part (a) provides less security but requires less code. The scheme illustrated 
in part (b) uses more guards, thereby adds more code to the application software program, but 

10 enjoys a benefit of better security. 

The present invention includes a flexible method for specifying the formations of the 
distributed networks of guards. Such a method allows the guard network formations to be 
specified coarsely or precisely, depending on the user's needs. For testing purposes or particular 
software programs, specifically defined guard network formations may be needed. For high 

15 volume production of self-protecting software programs, details of guard network formations 
may be left unspecified by the user in favor of randomized automatic specification by the present 
invention in a manner that meets the levels of security, cost, and software program execution 
performance desired by the user. 

One example of a distributed network of guards according to the present invention is 

20 called a directed-acycUc graph ("DAG"), where each node with an out-edge represents a guard 
and the node or nodes to which it points represent its client code. A DAG has no cycles, so 
guards do not protect each other in a circular manner. 
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FIG. 9A shows an example of a directed-acyclic graph according to the present invention, 
wherein the guard formation is a DAG whose nodes are either "brigade" nodes or "cUent group" 
nodes. A brigade node is a node with out-edges. A brigade node represents a group of 
checksumming and/or repair guards that, collectively, protect a number of client code blocks. 
5 For example, nodes B, C, Z), and E in FIG. 9A are brigade nodes. A client group node is a node 
pointed to by a brigade node. A client group node represents a set of basic blocks protected by a 
brigade node. For example, in FIG. 9A, ^ is a client group protected by both B and C, while 
C, and F are the client groups of B, Different client group nodes do not have basic blocks in 
common, 

10 Each DAG formation has a set of client group nodes with no out-edges called "roots," 

each of which denotes a disjoint set of host basic blocks protected by corresponding brigade 
nodes in the formation. For example, nodes A and F are the roots of the formation in the FIG. 
9A. 

This general guard formation scheme can be used for hiding low-level details of actual 
15 guard deployments which will be randomized within each brigade node, and for specifying 
precisely a particular network of guards when the number of guards in each brigade node is set to 
one. A software program can be protected by more than one guard formation. 

In an embodiment of the present invention, for each application software program, the 
user may specify to the system that creates the tamper resistant software a set of guard formation 
20 graphs, the set comprising at least one guard formation graph of the same general form as that 
shown in FIG. 9A. The set of guard formation graphs will contain general information about the 
guard protection scheme, but the details of what the guards are and how they protect the code 
may be left to the system that creates the tamper resistant software to implement. 
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Alternatively, the set of guard formation graphs, or any graph in the set of guard 
formation graphs, may be generated automatically by the system that creates the tamper resistant 
software based on a first and a secorid guard formation graph customization parameter to be 
supplied by the user. The first guard formation graph customization parameter is the number of 

5 brigade nodes protecting a root. The first guard formation graph customization parameter 
specifies the minimum level of protection assigned to each root node. The second guard 
formation graph customization parameter is the number of additional brigade nodes to be added 
to the formation. The second guard formation graph customization parameter may achieve a 
better and randomized final protection scheme. After the first guard formation graph 

10 customization parameter is applied, the beginning formation will be initialized with the roots 

r 

being protected by the given number of brigade nodes. Application of the second guard 
formation graph customization parameter results in more brigade nodes being added to the 
formation in a way that each new brigade node protects a random subset of the nodes in the 
existing guard formation graph. 
15 Each brigade node in every guard formation graph specified for an application software 

program is installed in an order in which its installation is complete before it becomes protected 
by another brigade node. To install each brigade node comprising at least one checksumming 
guard and associate it with its set of client group nodes, the following is done: r 
(1) Divide each client group node of basic blocks that has not previously been divided 
20 into subgroups of basic blocks, into subgroups^ and then for each subgroup form a code 

block using its basic blocks arranged in a randomized order. This code block is ready to 
be protected by checksumming guards. Dividing a client group node into subgroups of 
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basic blocks allows protected client code to be distributed in the final application 
software program listing. 

(2) Assign checksumming guards to protect each code block. This involves selecting 
a checksumming template for each checksumming guard, and selecting a portion of code 

5 within the code block to be its client code. The entire code block may, optionally, be 

selected as the client code. 

(3) Install each checksumming guard into a basic block that is not protected by a 
previously installed checksumming guard. This prevents the checksumming guards from 
forming a logical protection cycle (although logical protection cycles are desirable in 

10 some cases, as discussed hereinafter). The installation site of each checksumming guard 

may be selected either randomly, or by the user who specifies the location at which the 
checksunmiing guard is to be installed, or through analysis of an execution profile of the 
original application software program, for example, in order to avoid frequently executed 
regions of the application software program code where the presence of the 

15 checksununing guard code may have a larger negative effect on software program 

execution performance. 

A network of guards comprising an acyclic guard fonriation may be vulnerable to 
hackers. Using code analysis techniques known in the art, it may be possible for a hacker to 
detect one or more of the guards in the acyclic guard formation. As noted previously herein, if 
20 the hacker detects and attempts to override a guard whose integrity is protected by another guard, 
the altered guard will be detected and a defensive action will result, disrupting program 
operation. However, if the hacker detects an unguarded guard, such as the first guard in an 
acyclic guard formation, the hacker may be able to override the guard with impunity. Thereafter, 
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the hacker may be able to analyze the program instructions comprising the overridden guard to 
determine its client code block. If the client code block comprises a second guard in the acyclic 
guard formation, the hacker may be able to override the second guard. The hacker using this 
technique may be able to step through each guard in the acyclic guard formation until all guards 

5 in the acyclic guard formation have been defeated. Accordingly, it is desirable in some instances 
to have guards form logical protection cycles, hi a logical protection cycle, the integrity of each 
guard is protected by at least one other guard. There is no unprotected guard from which a 
hacker can launch an attack on the guard formation. The present invention is adaptable to permit 
cyclical guard formations. ^ 

10 Li a cyclic guard formation according to the present invention, the integrity of each guard 

is protected by another guard. Likewise, every guard in a cyclic guard formation according to the 
present invention operates to protect the integrity of another guard. Thus, where checksumming 
guards Goy ...,Ga-/ are checksumming guards in a CycHc guard formation and 0 < / < A: (where / is 
an integer index variable and 1 < k), every checksumming guard G/ in a cyclic guard formation 

15 has a client code block comprising another checksumming guard G,+imod^- Accordingly, each 
checksumming guard G/ comprises software code operable to compute the checksum of the cUent 
code block comprising checksumming guard G,+iaiodJt. Those of ordinary skill in the art will 
appreciate that the use of modular arithmetic is necessary to describe the cyclic nature of the 
guard formation. For notational simplicity, the variable t is used hereinafter to represent the 

20 expression "/ + 1 mod k," Jn equation form: 

/ = 1) modulo A: ^ 
FIG, 9B shows a diagrammatic example of a cyclic guard formation according to the 
present invention comprising six guards. In an implementation of the formation shown in FIG. 
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9B, checksumming guard Go protects the integrity of checksumming guard G/; checksumming 
guard G] protects the integrity of checksumming guard G2; checksumming guard G2 protects the 
integrity of checksumming guard G3; checksumming guard G3 protects the integrity of 
checksumming guard G4; checksumming guard G4 protects the integrity of checksumming guard 
5 G5; and checksumming guard G5 protects the integrity of checksumming guard Go- 

According to an embodiment of a cycUc guard formation, during the process of instalUng 
a checksumming guard Gy in an appHcation software program, an integer Ui is stored within the 
program instructions comprising the checksumming guard G/. Integer Ui is a randomly selected 
integer having a constant value. Preferably, a different integer a/ is stored within each 

10 checksumming guard G/ in an application software program, but this is not required. 

Associated with each checksumming guard G/ in this embodiment of a cyclic guard 
formation, but not stored within the program instructions comprising the checksumming guard 
G/, are two integers pi and 9,, each of which has a predetermined and constant value. Neither pi 
nor qi is stored anywhere within the appUcation software program containing the checksumming 

15 guard G/. According to this embodiment of a cyclic guard formation, each integer pi and integer 
qi comprises the following properties: 

• Each is a prime number 

• Pi + qi 

• Pi modulo Ui ^ 0 
20 • Ui modulo Pi 0 

• qi modulo ai f 0 

• fl/ modulo qi ^ 0 
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. The multiplicative product of integers /?/ and 9/ (denoted hereinafter as "p/^/") is computed 
as part of process of installing each checksumming guard G/ in the application software program. 
Multiplicative product piqi then is stored within the program instructions comprising the 
checksumming guard G,. Litegers pi and qi are selected so that it is difficult for an attacker to 
5 derive integers pi and qi from multiplicative product j9/^/. In an embodiment, integers pi and qt 
are large numbers. 

Each unaltered client code block comprising a checksumming guard G/ has a specific 
checksum, denoted as original checksum "C/." Each original checksum Q according to this 
embodiment of a cyclic checksumming guard formation has a multiplicative inverse modulo {pi - 

10 \){qi - 1), where "(p/ - \){qi - 1)" denotes the multiplicative product of integer (p, - 1) and integer 
{qi - 1). The multiplicative inverse of original checksum Q modulo (p, - \){qi - 1) is represented 
hereinafter by "C /," and satisfies the equation: 

Ct * Ct modulo ipi - l)(qi - I) = 1 
According to this embodiment of a cyclic guard formation, neither integer (p, - 1) nor 

15 integer (qt - 1) are stored within the program instructions comprising the checksumming guard 
G/, and the multiplicative product (pi - l)(qi - 1) also is not stored within the program instructions 
comprising the checksumming guard G/. Neither integer (p/ - 1), integer (qi - 1), nor 
multiplicative product (p/ - 1)(^/ - 1) are stored anywhere within the application software program 
comprising checksumming guard G/. 

20 Multiplicative inverse C't is computed as part of process of installing checksumming 

guard Gi in the application software program. However, multiplicative inverse C\ is not stored 
within the program instructions comprising the checksumming guard G/. Multiplicative inverse ^ 
C't is not stored anywhere within the application software program. A practitioner of the present 
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invention is advised that, to ensure that a multiplicative inverse Ct exists in every case, the 
values of pi and qi are selected so that for a given original checksum Q there is a multiplicative 
inverse C't which satisfies the above-defined equation. Li an implementation of the present 
invention, random values of integers pi and qi are tested until a set of pi and q^ is found which 
5 satisfies the above-defined equation. 

A constant Ri is associated with each checksumming guard G, in an embodiment of a 
cychc guard formation according to the present invention. The value of each constant i?/ is 
calculated according to the following equation: 

Ri = ai ^ modulo ptqi 

10 Constant Ri is computed as part of process of installing checksumming guard d in the 

application software program after (1) integer is selected for checksumming guard G/, (2) 
integers pi and qi are selected and multiplicative product piqi is calculated, and (3) original 
checksum Q and its multiplicative inverse d are computed. Recall that integers and 
originar checksum Q, and multiplicative inverse C\ are not retained anywhere in the application 

15 software prograni after constant Ri is computed. 

Each constant Ri is stored in the application software program. Although each constant /?, 
is associated with a checksumming guard G, in this embodiment of a cyclic checksumming guard 
formation, the constant Ri is not necessarily stored within the program instructions comprising its 
associated checksumming guard G,. Each constant Ri may be stored anywhere in the application 

20 software program, provided, however, that in this embodiment of a cyclic guard formation, at 
least one constant Ri must be stored outside the cyclic guard formation. In other words, at least 
one constant Ri must not form part of the client code block of any checksumming guard Gi in the 
cycHc guard formation. 
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In operation of a cyclic guard formation according to this embodiment, when the program 
instructions comprising a checksumming guard G, are executed during run-time, the checksum of 
the cHent code block comprising checksumming guard Gt is calculated at least one time. The 
checksum of the client code block comprising checksumming guard Gt calculated during 
5 program execution is denoted as calculated checksum "Xt" 

Using the value of constant Ri stored in the application software program, and the value 
of checksum Xt calculated during run-time, checksunmiing guard G/ then performs a conditional 
computation to determine if the cHent code block comprising checksumming gu^d Gt has 
changed. If the client code block comprising checksumming guard Gt is unchanged, calculated 
10 checksum Xt will be the same as original checksum and a conditional computation comprising 
the following equation will hold true: 

Ri^^ modulo piqi - at 

This is because: 

Ri ' modulo Piqi = («/ ') ' modulo piqi 
15 and 

(a/^')^' modulo j!?/^/ = a/ 
Recall that that neither original checksum Ct nor its multiplicative inverse C\ appear 
anywhere in the application software program. Multiplicative inverse C\ is shown in the above 
equations only to explain the operation of the i?,^' modulo ptqi = ai property. 
20 If the conditional computation comprising the Ri^^ modulo piqi = Ui equation holds true, 

execution of the application software program proceeds normally. However, if the client code 
block comprising checksumming guard Gt has changed, such as, for example, through the actions 

of a hacker, checksum Xt calculated during program execution will be different fi'om original 

0 
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checksum Q calculated during the installation of checksumming guard G/. Tlie conditional 
computation comprising the above function will not hold true, and checksumming guard d will 
take a defensive action. 

In an embodiment of the present invention comprising a cyclic guard formation, one or 

5 more instances of the Ri^' modulo piqi^ at property may be adapted to comprise one or more 
conditional identity functions. Such a conditional identity function then may be added to one or 
more expressions from the application software program as described herein, so that correct 
execution of the one or more application software program expressions depends upon the value 
of checksum Xt calculated by checksumming guard G/ during program execution. When a 

10 calculated checksum Xt matches the anticipated value (i.e., original checksum C/), the conditional 
identity function evaluates to "0" or "1," as required to maintain computational accuracy of the 
application software program expression selected for modification, and the application software 
program execution proceeds normally. When a calculated checksum Xt differs from the 
anticipated value, the conditional identity function does not evaluate to "0" or "1" or another 

15 number or value (as required to maintain computational accuracy), resulting in a defensive 
action. 

The fact that integers pt and ^/ are not known to, and not readily discoverable by, an 
attacker makes it difficult for the attacker to modify a checksumming guard Gt and perform a 
corresponding modification to constant /?/ that maintains the i?/^' modulo piqt = at property. A 
20 modification to a checksumming guard Gt changes its checksum in a way detectable by 
checksumming guard G,. Thus, to modify a checksumming guard Gt without causing 
checksumming guard G/ to take a defensive action upon detection of the different checksum of 
modified checksumming guard Gt requires concurrently computing a new multiplicative inverse 
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(modulo {pi - l)(qi - 1)) of the checksum of modified checksumming guard G/, which is difficult 
to carry out without knowing integers qj, (pi - 1), and/or (qi - 1). 

In another embodiment of a distributed network of guards according to the present 
invention, the principles discussed above in regard to cyclic guard formations may be^ adapted to 
apply to "polycyclic guard formations." Polycyclic guard formations according to the present 
invention are strongly connected. In a polycyclic guard formation according to the present 
invention, the integrity of each guard is protected by at least one other guard. Likewise, every 
guard in a polycyclic guard formation according to the present invention operates to protect the 
integrity of at least one other guard. 

In an embodiment of a polycyclic guard formation according to the present invention, 
polycyclic guard formation N comprises n guards which, in this embodiment, are designated as 
checksumming guards Gft...,G„_/. Each such checksumming guard G, in polycyclic guard 
formation has one or more cHent code blocks, wherein each client code block comprises at 
least one other checksumming guard Gj (where / and j are integer index variables) in polycyblic 
guard formation A^. The following properties apply in this embodiment of a polycyclic guard 
formation according to the present invention: ^ 

• 0<i<n 

• 0<j<n 

• Kn 

The set of one or more checksumming guards Gj comprising the client code of a 
checksumming guard G/ is called list L(i), Each checksumming guard d is operable to compute 
the checksum of each client code block comprising at least one checksumming guard Gj in list 
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FIG. 9C shows a diagrammatic example of a polycyclic guard formation according to the 
present invention comprising six guards, hi an implementation of the formation shown in FIG. 
9C, checksumming guard Go protects the integrity of checksumming guards Gy and Qr, 
checksumming guard Gy protects the integrity of checksumming guards Gj and Gj; 
checksumming guard G2 protects the integrity of checksumming, guard Gy; checksumming guard 
Gj protects the integrity of checksumming guards G2 and G^; checksumming guard G4 protects 
the integrity of checksumming guard G2; and checksumming guard Gj protects the integrity of 
checksumming guards Go and G4. 

An embodiment of a polycyclic guard formation comprises many of the features of a 
cyclic guard formation embodiment previously discussed herein. In an embodiment of a 
polycyclic guard formation, an integer a, is stored within the program instructions comprising 
each checksumming guard G, during the process of installing the checksumming guard G, in the 
apphcation software program. Integer ai is a randomly selected integer having a constant value. 
A different integer ai is stored within each checksumming guard G„ but this is not required. 

Associated with each checksumming guard G, in this embodiment of a polycyclic guard 
formation, but not stored within the program instructions comprising the checksumming guard 
G„ are two integers pi and qi, each of which has a predetermined and constant value, and each of 
which comprises the properties discussed previously herein in regard to a cyclic guard formation. 
Neither integer pi nor integer qi is stored anywhere within the application software program 
comprising checksumming guard G/. A multiplicative product piqi is computed as part of process 
of installing a checksumming guard G/ in the application software program. Multiplicative 
product piqi then is stored within the program instructions comprising the checksumming guard 
G/, as was the case in a cyclic guard formation. 



P00620-US-01 



59 



In an embodiment of a polycyclic guard formation, each unaltered client code bock 
comprising a checksumming guard Gj has a specific checksum, denoted as original checksum 
"Q." Each original checksum Q according to this embodiment of a polycyclic guard formation 
has a muhiplicative inverse modulo {pi - l)(qi - 1). The multiplicative inverse of original 
5 checksum Cj modulo (pi - - 1) is represented hereinafter by "Cy," and satisfies the equation: 

Cj * Cj modulo (pi - 1)(9/ - 1) =1 
Multiplicative inverse Cj is computed as part of process of installing checksumming 
guard Gi in the application software program. However, multiplicative inverse Cj is not stored 
within the program instructions comprising the checksumming guard G/. Multiplicative inverse 
10 Cj is not stored anywhere within the, application software program. As recommended in regard 
to a cyclic guard formation, a practitioner using this embodiment of a polycyclic guard formation 
is advised that, to make sure that such a multiplicative inverse exists, the values of pi and 9, are 
selected so that for every original checksum Cj there is a multiplicative inverse Cj which satisfies 
the above-defined equation. Li an implementation of the present invention, random values of pi 
15 and qi are tested until a set of pi and qi is found which satisfies the above-defined equation. 

According to this embodiment of a polycyclic guard formation, neither integer (pi- 1) nor 
integer (qi - 1) are stored within the program instructions comprising the checksumming guard 
G/, and the multiplicative product (pi - l)(qi - 1) also is not stored within the program instructions 
comprising the checksumming guard d. Neither integer (pi - 1), integer (q^ - 1), nor 
20 multiplicative product - l){qi - 1) is stored anywhere within the application software program 
comprising checksumming guard G,. 

A constant Rij is associated with each relationship between a checksumming guard G/ and 
its client code block comprising a checksumming guard Gj according to this embodiment of a 
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polycyclic guard formation. The value of each constant Rij is calculated according to the 
following equation: 

Rij^Ui ^ modulo 

Constant Rij is computed as part of process of installing checksumming guard G/ in the 

5 application software program after (1) integer ai is selected for checksumming guard G/, (2) 
integers pi and qi are selected and multiplicative product piqi is calculated, and (3) original 
checksum Cj and its multiplicative inverse Cj are computed. Recall that integers Pi and qi, 
original checksum Cy, and multiphcative inverse C) are not retained anywhere in the application 
software program after constant Rq is computed. 

10 Each constant Rij is stored in the application software program. Each constant Rij may be 

stored anywhere in the application software program, provided, however, that in a polycycUc 
guard formation at least one constant Rij must be stored outside the polycyclic guard formation. 
In other words, at least one constant Rij must not form part of the client code block of any 
checksumming guard G/ in the polycyclic guard formation. 

15 hi operation of a polycyclic guard formation according to this embodiment, when the 

application software program instructions comprising a checksumming guard G/ are executed 
during run-time, the checksum of the client code block comprising checksumming guard Gj is 
calculated at least one time. The checksum of the client code block comprising checksumming 
guard Gj calculated during program execution is denoted as calculated checksum 

20 Using the value of constant Ri stored in the application software program, and the value 

of checksum Xj calculated during run-time, checksumming guard G, then performs a conditional 
computation to determine if the cUent code block comprising checksumming guard Gj has been 
changed. If the client code block comprising checksumming guard Gj is unchanged, calculated 
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checksum Xj will be the same as original checksum Q, and a conditional computation comprising 
the following equation holds true: 

Rij ^ modulo piQi = ai 

This is because: 

5 Rif^ modulo piqi = {ap^Y^ modulo piqi 

and 

{a^^Y^ modulo piqi = au 
Recall, however, that neither original checksum Q nor its multiplicative inverse C) 
appear anywhere in the application software program. Multiplicative inverse C) is shown in the 
10 above equations only to explain the operation of the Rtf^ modulo ptqi = a/ property. 

If the conditional computation comprising the Rif^ modulo ptqi = at equation holds true, 
execution of the application software program proceeds normally. However, if the chent code 
block coniprising checksumming guard Gj has changed, such as, for example, through the actions 
of a hacker, checksum Xj calculated during program execution will be different fi^om original 
15 checksum Cj calculated during installation of checksumming guard G/. The conditional 
' computation comprising the above fiinction will not hold true, and checksumming guard G/ will 
take a defensive action. 

In an embodiment of the present invention comprising a polycyclic guard formation, one 
or more instances of the Rtf^ modulo ptqi = a, property may be adapted to comprise one or more 
20 conditional identity functions. Such a conditional identity function then may be added to one or 
more expressions fi-om the application software program as described herein, so that correct 
execution of the one or more appHcation software program expressions depends upon the value 
of checksum Xj calculated by checksumming guard G/ during program execution. When a 
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calculated checksum A/ matches the anticipated value (i.e., original checksum Q), the conditional 
identity function evaluates to "0" or "1," as required to maintain computational accuracy of the 
appUcation software program expression selected for modification, and the application software 
program execution proceeds normally. When a calculated checksum Xj differs from the 
5 anticipated value, the conditional identity fimction does not evaluate to "0" or "1" or another 
number or value (as required to maintain computational accuracy), resulting in a defensive 
action. 

As was the case in the cyclic guard formation, the fact that /?/ and qi in a polycyclic guard 
formation are not known to, and not readily discoverable by, an attacker makes it difficult for the 

10 attacker to modify a checksumming guard Gj and perform a corresponding modification to 
constant Rq that maintains the Rif^ modulo piqi = a/ property. A modification to a 
checksumming guard Gj changes its checksum in a way detectable by checksumming guard G,. 
Thus, to modify a checksumming guard Gj without causing checksumming guard G/ to take a 
defensive action upon detection of the different checksum of modified checksumming guard Gj, 

15 requires concurrently computing a new multiplicative inverse (modulo (p, - 1)(^, - 1)) of the 
checksum of modified checksumming guard Gj, which is difficult to carry out without knowing 
integers /?/, qi, (pi ~ 1), and/or (qi - 1). 

hi a second embodiment of a polycyclic guard formation according to the present 
invention, an asymmetric key encryption technique comprising a public-private key pair is used. 

20 Encryption is known by those of skill in the art to be a process by which data is translated into an 
unintelligible form using a predefined encryption algorithm, hi asymmetric key encryption the 
data can be encrypted and decrypted by two different "keys." hi practice, one such key is made 
available to the public, and the other such key is held privately. 

/ 
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According to this second embodiment of a polycyclic guard formation, "£'(•)" denotes the 
public key, and "!)(•)" denotes the private key. Pubhc key £"(•) is stored within the apphcation 
software program. Optionally, the public key can be stored in the program instructions 
comprising a checksumming guard, but this is not required. Private key /)(•) is not stored 

5 anywhere in the application software program. 

A polycyclic guard formation N according to this second embodiment comprises n 
guards, which in an implementation of this embodiment comprise checksumming guards 
Go....,Gn.]. Every checksumming guard G, in polycycUc guard formation has one or more 
client code blocks, and wherein each such cHent code block comprises at least one other 

10 checksumming guard Gj in polycycUc guard formation N. The following properties apply in this 
second embodiment of a polycyclic guard formation: 

• 0<i<n 

• 0<j<n 

• 1<«' 

15 The set of one or more checksumming guards Gj comprising the client code of a 

checksumming guard G, in this second embodiment of a polycyclic guard formation is called list 
Each checksumming guard G/ is operable to compute the checksum of each client code 
block comprising a checksumming guard Gj in list L{i), As in the first embodiment of a 
polycyclic guard formation according to the present invention, in this embodiment each unaltered 

20 client code bock comprising a checksumming guard Gj has a specific checksum, denoted as 

i 

original checksum Q. 
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Associated with each checksumming guard Gj in this second embodiment of a polycycUc 
guard formation is a constant Rp whose value is the same as the value of original checksum Q 
encrypted using the private key. hi equation form: 

Rj-D(Cj) 

During the process of installing checksumming guard G/ in the application software 
program, the value of original checksum Q is computed. Then, constant Rj is computed using 
the value of original checksum Cj and the private key /)(•)• The value of original checksum Cy 
and private key D(*) are not retained anywhere in the application software program after constant 
Rj is computed. 

Each constant Rj is stored in the application software program. Each constant Rj may be 
stored anywhere in the application software program, provided, however, that in a polycyclic 
guard formation at least one constant Rj must be stored outside the polycyclic guard formation, 
hi other words, at least one constant Rj must not form part of the client code block of any 
checksumming guard G, in the polycyclic guard formation. 

The operation of this second embodiment of a polycyclic guard formation according to 
the present invention is similar to the operation of the first embodiment. When the program 
instructions comprising a checksumming guard G, are executed during run-time, the checksum of 
the chent code block comprising checksumming guard Gy is calculated at least one time. The 
checksum of the client code block comprising checksumming guard Gy calculated during 
program execution is denoted as calculated checksum Xj. Checksumming guard G, performs a 
conditional computation to determine if the client code block comprising checksumming guard 
Gy has changed. If the client code block comprising checksumming guard Gy is unchanged, the 
value of calculated checksum Xj will be the same as the value of constant Rj decrypted using the 
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public key, indicating that the value of calculated checksum Xj is the same as the value of 
original checksum Cj calculated during installation of checksuniming guard Qt, hi other words, if 
the client code block comprising checksumming guard Gj is unchanged, a conditional 
computation comprising the following equation holds true: 
5 Xj-E{Rj) 

If the conditional computation comprising the Xj = E{Rj) equation holds true, execution of 
the application software program proceeds normally. However, if the client code block 
comprising checksumming guard Gj has changed, such as, for example, through the actions of a 
hacker, checksum Xj calculated during program execution will be different from value of 
10 constant Rj decrypted using the public key, indicating that the value of calculated checksum Xj is 
different from the value of original checksum Cj calculated during installation of checksumming 
guard Gi, Thus, the conditional computation comprising the above equation will not hold true, 
and checksumming guard G, will take a defensive action. 

Alternatively, instead of a single public-private key pair for all checksumming guards in 
15 this second embodiment of a polycyclic guard formation, a different public-private key pair could 
be used for each checksumming guard G/ in polycyclic guard formation N. Li this alternative 
implementation, "£'/(•)" denotes the public key of checksumming guard G/, and ''Di(*)" denotes 
the private key of checksumming guard G/. 

According to this altemative implementation of a polycyclic guard formation, a constant 
20 Rij is associated with each relationship between a checksumming guard G/ and a client code 
block comprising a checksumming guard Gj, Each constant Rij is calculated as follows: 

Rij = DiCj) 
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During the process of installing each checksumming guard d in the application software 
program, the value of original checksum Q is computed. Then, constant Rij is computed using 
the computed value of original checksum Cj and the private key The values of original 

checksum Cj and private key A(*) are not retained anywhere in the application software program 
5 after constant Rtj is computed. 

Each constant Rij is stored in the application software program. Each constant Rij may be 
stored anywhere in the application software program, provided, however, that in a polycyclic 
guard formation at least one Rjj must be stored outside the polycyclic guard formation. In other 
words, at least one R^j must not form part of the client code block of any checksumming guard d 

10 in the polycyclic guard formation. 

hi operation, when the program instructions comprising a checksumming guard G/ are 
executed during run-time, the checksum Xj of the client code block comprising checksumming 
guard Gj is calculated at least one time. Checksumming guard G/ performs a conditional 
computation to determine if the client code block comprising checksumming guard Gj has 

15 changed. If the client code block comprising checksumming guard Gj is unchanged, the value of 
calculated checksum Xj will be the same as the value of constant Rij decrypted using the public 
key, indicating that the value of checksum Xf calculated during run-time is the same as the value 
of original checksum Q calculated during the installation of checksumming guard G/. In other 
words, if the client code block comprising checksumming guard Gj is unchanged, a conditional 

20 computation comprising the following equation holds true: 

If the conditional computation comprising the Xj = Ei(Rij) equation holds true, execution 
of the application software program proceeds normally. However, if the client code block 
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comprising checksumming guard Gj has changed, such as, for example, through the actions of a 
hacker, checksum Xj calculated during program execution is different from original checksum Cy 
calculated during installation of checksumming guard G/. Thus, the value of calculated 
checksum Xj is not the same as the value of constant Rij decrypted using the public key. The 

5 conditional computation comprising the above equation will not hold true, and checksumming 
guard Gi will take a defensive action. j 

In an implementation of this second embodiment of a polycyclic guard formation 
according to the present invention, each comparison of calculated checksum Xj to decrypted 
constant Rj (or Rq as the case may be) may be adapted to comprise one or more conditional 

10 identity functions. Such a conditional identity function then may be added to one or more 
expressions from the application software program as described herein, so that correct execution 
of the one or more application software program expressions depends upon the value of 
checksum Xj calculated by checksumming guard G, during program execution. When a 
calculated checksum^ matches the anticipated value (i.e., original checksum Q), the conditional 

15 identity function evaluates to "0" or "1," as required to maintain computational accuracy of the 
application software program expression selected for modification, and the application software 
program execution proceeds normally. When a calculated checksum Xj differs from the 
anticipated value, the conditional identity function does not evaluate to "0" or "1" or another 
number I or value (as required to maintain computational accuracy), resulting in a defensive 

20 action. 

hi this second embodiment of a polycyclic guard formation according to the present 
invention, it is necessary for the value of original checksum Cj and calculated checksum Xj to be 
computed using a one-way function, such as, for example, a one-way hash function. If 
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checksumming is not performed using a one-way function, a hacker can replace Rj (or Rij as the 
case may be) by a random number r of his choice. Thus, random number r could be used in 
place of Z)(Cy). Then the hacker could manipulate the client code block of checksumming guard 
Gi until its calculated checksum Xj equals E{r\ such as, for example, l^y adding or subtracting 

5 bits in the checksimimed client code block, and/or by'the use of other manipulation techniques as 
would occur to those of ordinary skill in the art. Manipulating the client code block of a 
checksumming guard Gi until calculated checksum Xj equals the targeted E{r) becomes 
impossible if calculated checksum Xj is computed using a one-way fimction, because changes to 
the client code block of a checksumming guard G/ may not result in proportionate changes to 

10 calculated checksum Xj. 

It is within the scope of the present invention that a network of guards may be 
dynamically determined at the time of program execution. Accordingly, the appearance of a 
network of guards in a particular copy of an apphcation software program may change from one 
execution of the application software program to the next. Thus, a hacker observing operation of 

15 the copy of the application software program will have difficulty identifying and defeating all 
guards present in the program. 

According to an embodiment of a dynamically determined network of guards, list L{i) 
comprises the set of one or more checksumming guards Gj comprising the client code of a 
checksumming guard G,. Checksumming guard G/ is operable to compute the checksum of one 

20 or more client code blocks comprising a checksumming guard Gj in list Z(/). At run-time, a 
subset of list L{i) comprising one or more (but preferably fewer than all) checksumming guards 
Gj of hst L(i) is selected for protection by checksumming guard Gi, hi other words, the program 

instructions of checksumming guard G/ calculate checksums of only the client code blocks 

; 
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comprising those checksumming guards Gj of Ust L{i) selected at run-time, and then perform one 
or more conditional computations using one or more of the values of the calculated checksums. 

In a first embodiment of an application software program comprising a dynamically 
determined network of guards, prior to program execution the program code of the application 

5 software program comprises a plurality of checksumming guards G,. Prior to program execution, 
the program code of each checksumming guard G, comprises the ability to calculate checksums 
of all checksumming guards Gj of list I(z), and to perform conditional computations using the 
calculated checksums. However, in this first embodiment of an application software program 
adapted to dynamically determine a network of guards, the program code of the application 

10 software program also comprises one or more conditional instructions which "disable" certain 
program instructions based on, for example, the presence, absence, or value of a certain variable. 
The disabled program instructions comprise those program instructions which otherwise would 
have caused checksumming guard G/ to calculate checksums of certain checksumming guards Gj 
of list and to perform conditional computations using the calculated checksums. 

15 In a second embodiment of an application software program comprising a dynamically 

determined network of guards, prior to program execution the program code of the appUcation 

software program also comprises a plurality of checksumming guards G,. However, prior to 

program execution, the program code of each checksumming guard G/ does not have the ability 

to calculate checksums of all checksumming guards Gy of Ust or to perform conditional 

20 computations using the calculated checksums. However, in this second embodiment of an 

.J ' 
application software program adapted to dynamically determine a network of guards, the 

program code of the application software program also comprises one or more conditional 

instructions which "activate" certain program instructions based on, for example, the presence. 
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absence, or value of a certain variable. The activated program instructions comprise those 
program instructions that cause checksumming guard d to calculate checksums of certain 
checksumming guards Gj of list L(i) and to perform conditional computations using the 
calculated checksums. 

5 Although the operation of dynamic networks of guards is discussed herein in terms of 

"disabled" and "active" checksuniming guards, the program instructions comprising every 
checksumming guard (whether disabled or active) in the application software program remains 
present in each copy of the appUcation software program. 

Examples of dynamically determined networks of guards can be shown by reference to 

10 FIGS. 9C-F. FIG. 9C shows a diagrammatic example of a network of guards according to the 
present invention comprising six guards. In an implementation of the network of guards shown 
in FIG. 9C, the guards comprise checksumming guards. FIGS. 9D-F each show a diagrammatic 
example of a dynamically determined network of guards according to the present invention, 
based on the network of guards shown in FIG. 9C. 

15 A simple example of the implementation of a dynamic network of guards is shown in 

FIGS, 9D-E. The implementation of the network of guards shown in FIG, 9D is the inverse of 
the implementation of the network of guards shown in FIG. 9E. Thus, in the implementation of 
the network of guards shown in FIG. 9D, checksumming guards Goy G2, and G4 are disabled, 
leaving checksumming guards G/, Gj, and Gj as the remaining active guards in the network. In 

20 the implementation of the network of guards shown in FIG. 9E, checksumming guards G/, Gj, 
and Gj are disabled, leaving checksumming guards G^, G2, and G4 as the remaining active guards 
in the network. As shown in FIGS. 9D-E, the disabled guards remain in the application software 
program, but their program instructions are not executed. 
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In an implementation of a dynamic network of guards according to FIGS. 9D-E, the 
means for selecting the guard formation of FIG. 9D versus the guard formation of FIG. 9E is 
contained in the program code of the application software program. For example, the application 
software program may comprise a Boolean variable, the value of which is "true" (or "1") under 
5 certain conditions, and is "false" (or "0") under other conditions. The value of the Boolean 
variable may control whether the network of guards according to FIG. 9D, or the network of 
guards according to FIG. 9E, is selected during execution of the application software program. 
For example, if the Boolean variable evaluates to "true," the guard network of FIG. 9D is 
selected, and if the Boolean variable evaluates to "false," the guard network of FIG. 9E is 

10 selected. In an embodiment, the evaluation is performed only one time during execution of the 
application software program, before the program instructions comprising any of the guards in 
the guard formation are executed. Thus, the selected guard formation is static for the remainder 
of the execution of the application software program n this embodiment. 

The use of a Boolean variable is merely one example of a process for dynamically 

15 determining a network of guards. In another example, the application may contain a sine 
function whose output based on a given angle controls the dynamic network of guards. For 
example, if sin(x) < -0.5, a first network of guards is used; if -0.5 < sin(jc) < 0.5, a second 
network of guards is used; if sin(x) > 0.5, a third network of guards is used. 

In another example, in an application software program comprising a computer game, the 

20 player may be required to move to the left or to the right (or up/down, forward^ackward, etc). It 
is known to use a global variable to capture leftward or rightward movement. A dynamically 
determined network of guards according to the present invention may determine which guards to 
disable or activate based on the value of this movement variable. 
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The means for controlling the dynamic determination of a network of guards can differ 
from one application software program to the next, or from one implementation of a dynamic 
network of guards in an application software program to the next. Any variable in an application 
software program whose value is subject to change randomly or pseudo-randomly is a good 
5 candidate for a variable to control a dynamically determined network of guards, hi addition, a 
variable may comprise an input to an algorithm which controls the dynamically determined 
network of guards. 

FIG. 9F shows another example of a dynamically determined network of guards 
according to the present invention, based on the network of guards shown in FIG. 9C. Based on, 

10 for example, the presence, absence, or value of a certain variable, or based on the result of a 
certain fiinction, checksumming guards G2 and G4 are disabled in the implementation of the 
network of guards shown, in FIG. 9F. 

Repair guards according to the present invention also may be adapted to be dynamically 
determined. In an embodiment of dynamically determined repair guards, two or more repair 

15 guards are adapted so that a repair involves actions that change dynamically, but that 
cumulatively amount to the same repair. For example, a network of guards may comprise two or 
more repair guards, each of which comprises the ability to overwrite a client code block in the 
application software program with one of a plurahty of repair code blocks. In operation, the 
application software program is adapted so that the repair code block(s) which overwrite client 

20 code within the apphcation software program are randomly selected, but cumulative operation of 
the randomly selected repair code blocks amounts to the full repair of the chent code block. 

In an exemplary implementation of dynamically determined repair guards, the desired 
code repair in an application software program consists of adding 7 to an important constant in 
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the program before the constant is used. A first repair guard has a first repair code block which 
cornprises overwriting the cUent code block in the application software program so that a 
variable x is added to the important constant. The value of variable x changes with each 
execution of the application software program. A second repair guard has a first repair code 

5' block which comprises overwriting the client code block in the appUcation software program in a 
manner that "7-x" is added to the important constant. Both repair guards are executed in concert, 
and the cumulative effect of this repair is that "jc + 7 - jc" is added to the important constant, thus 
initializing the constant to the desired value. 

hi an adaptation of this example, the first repair guard also has a second repair code block 

10 which comprises overwriting the cUent code block in the application software program so that 7 
added directly to the important constant (no variables are used). The second repair guard also 
has a second repair code block comprising a null operation. Again, both repair guards are 
executed in concert, and the cumulative effect of this repair is that 7 is added to the important 
constant, initializing the constant to the desired value. Alternatively, the application software 

15 program may be adapted so that when the second repair code block of the first repair guard is 
selected, the second repair guard is not executed. The result again is that 7 is added to the 
important constant in the program before the constant is used. 

An application software program may be adapted so that the repair code block(s) which 
overwrite client code within the application software program are randomly selected fi*om a 

20 group of repair code block(s) in a way that results in the repair guards operating in a concerted 
manner to accomplished a desired repair. 

Multithreaded application software programs also may be adapted to comprise 
dynamically determined repair guards. For example, in a first execution a repair could be 
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accomplished by a first repair guard, and in a second execution a repair could be accomplished 
by a second guard. 

FIG. 9G shows another example of a network of guards according to the present 
invention. In the network of guards shown in FIG. 9G, two security-sensitive regions of an 
5 application software program, labeled as "CI" and "C2," are protected by both checksumming 
guards and repair guards. Part (a) of FIG. 9G shows a computer memory image of the 
application software program in which regions CI and C2 are guarded by guards Gl, G2, G3, 
G4, and G5. Guards Gl, G4, and G5 are checksumming guards, and guards G2 and G3 are 
repair guards. 

10 This network of guards is alternatively depicted in a guard graph shown in part (b) of 

FIG. 9G. The dependencies between and among guards Gl, G2, G3, G4, and G5, and regions CI 
and C2 can be understood by analyzing the arrows ("->") shown in part (b) of FIG. 9G. 
Accordingly, region CI is repaired by repair guard G3 before region CI executes. The repaired 

region CI subsequently will be checksummed by checksumming guards Gl and G5. However, 

( 

15 repair guard G2 must repair checksumming guard G5 before checksumming guard G5 executes. 

In operation, a network of guards must appear in the execution flow of an application 
software program in an appropriate way. For example, a repair guard has to be inserted into a . 
point in the execution flow that is to be reached first (in execution order) before its client code 

( 

block is reached. In other words, a repair guard "dominates" its client code in their respective 
20 execution flow locations. Similarly, a checksumming guard must appear in the execution flow of 
an application software program at a point where its client code already is present in computer 
memory. Thus, the client code block of a checksumming guard dominates the checksumming 
guard in their respective execution flow locations. 
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FIG. 9H shows a partial guard graph that depicts the dominance relationships between 
different pairs of the nodes shown in part (b) of FIG. 9G. Dominance is shown by the direction 
of the arrows in FIG. 9H. Thus, "G3 Gl" means the location of repair guard G3 dominates 
that of checksumming guard Gl. FIG. 91 shows two possible scenarios in which the network of 
5 guards can be installed into the execution flow of an application software program without 
violating the partial ordering of their executions specified in FIG. 9H. The larger an application 
software program, the more ways there are to deploy a network of guards. 

-J 

^ A software program protection scheme relying entirely on one guard or on a distributed 
network of guards is vulnerable to a collusion attack, in which two or more similarly protected 

10 copies of the application software program are comjiared instruction-by-instruction. Any 
differences in the code will signal possible presence of a guard. To thwart such attacks, the 
application software program code may be disguised. 

The technique of code disguise is a method that, given a valid software program, 
rearranges or otherwise modifies the software program to produce another valid and fimctionally 

15 equivalent software program that is difficult to understand and analyze; and that is also becomes 
guarded against tampering. Simple obfuscating transformations such as register reallocation and 
reshuffling of instructions and/or basic blocks have limited effectiveness. These transformations 
tend to produce local changes to the code, while leaving the global control flow patterns almost 
intact. Local changes which maintain the same global control flow patterns make code 

20 deobfuscation, the reverse transformation of code obfuscation, and similar analyses of the code 
almost as easy as before obfuscation. Effective code disguise therefore requires more aggressive 
methods than obfuscation for rendering the code unintelligible. 
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A technique for obfuscating application software program code comprising guards 
involves the use of mathematical identities. For example, given the same input, two different 
mathematical expressions may provide the same output value. Thus, they can be substituted for 
one another with no loss of computational accuracy. In another example, a result of a first 
mathematical expression may be used in a second mathematical expression without affecting the 
computational accuracy of the second mathematical expression. However, the second 
mathematical expression is made more difficult to analyze. 

This technique can be demonstrated by an example based on the following sample 
pseudocode segment previously introduced herein: 



1 F-0 

2 Compute XI 

3 Compute X 

4 F=l 

5 If(X = TRUE)GoToL 

6 Take Defensive Action 

7 L If(F = 0)GoToLl 

8 V - Z * (A*Z + B) + 72 //sample computation of V 

9 Y1=X1-T1 

10 V = V+Y1 

11 LI Continue 
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To disguise the guarding contained in this sample pseudocode segment, an identity 
function I(Z,Z1) is introduced. The identity function I(Z,Z1) evaluates to 0 when Z = Zl. 
Accordingly, such an identity function may be a simple expression such as I(Z,Z1) = Zl - Z. 
Alternatively, such an identity function may comprise a complex algorithm having thousands of 
5 lines of software program code. 

To illustrate disguise using an identity function, the pseudocode expression shown at line 
9 in the above pseudocode segment is replaced by Yl = I(T1,X1)*F in the following example. 
The resulting pseudocode segment is as follows: 



10 1 F = 0 

2 Compute XI 

3 Compute X 

4 F = l 

5 If(X = TRUE)GoToL 
15 6 Take Defensive Action 

7 L If(F-0)GoToLl 

8 V = Z * (A*Z + B) + 72 //sample computation of V 

9 Yl -I(T1,X1)*F 

10 V = V+Y1 
20 11 LI Continue 



In this pseudocode segment, Yl will equal 0 if either the value of F is 0 (i.e., the 
pseudocode program instruction shown as line 4 has not been executed) or if identity function 
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I(T1,X1) evaluates to 0 (i.e., the pseudocode program instruction shown at Une 2 has been 
executed and variable XI equals the expected value Tl). Note, however, that if the value of F is 
0, execution of the pseudocode program instruction shown at line 7 causes the computation of Yl 
at line 9 to be skipped. The application software program does not execute properly unless the 

5 value of F is incremented properly. The use of variable XI in identity function I(T1,X1) 
illustrates a silent guard according to the present invention. The application software program 
does not execute properly unless the value of variable XI equals the expected value Tl. The 
value of variable XI will not equal the expected value Tl if the client code block comprising 
variable XI has been altered. 

10 If Yl = 0, then the value of program variable V does not change in the computation 

shown as line 10. However, if Yl ,^0, the computation of program variable V at line 10 will 
result in an inaccurate value for program variable V. 

The purpose of using an identity function to disguise the guarding scheme is twofold. 
First, there is no test to identify a possible point of failure. Unlike an expUcit conditional 

15 branching or conditional jump statement which may be relatively easy to detect by a hacker, the 
operation of a mathematical identify function according to the present invention is implicit. 
Thus, the use of mathematical identities may be less readily detectible. 

Second, because the identity function I(T1,X1) may comprise a large number of lines of 
program code, such code disguises the calculation of program variable V, Indeed, although the 

20 computation of program variable V is shown in the above pseudocode list as occurring prior to 
the computation of variable Yl, where identity function I(T1,X1) comprises a plurality of lines of 
program code, the expression(s) computing program variable V may be interleaved among the 
plurality of lines of program code comprising identity function I(T1,X1). 
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Flag variable F also can be disguised using an identity relationship. In one example, a 
new variable R is introduced. Variable R is initialized to a random value. Flag variable F is 
initialized to be equal to R. Variable R and flag variable F then are subjected to one or more , 
computations, with the result remaining that the value of flag variable F is 1 after the guard code 
5 (beginning at label G) is executed. In one example, the pseudocode segment from the previous 
example is adapted as follows: 





1 


R = random value 




2 


F = R 


10 


3 


Compute XI 




4 


Compute X 




5 


R = F^-F*R 




6 


F = R+ 1 




7 


If (X = TRUE) Go To L 


15 


8 


Take Defensive Action 




9 


L If(F = 0)GoToLl 




10 


V = Z*(A*Z + B) + 72 




11 


Yl =I(T1,X1)*F 




12 


V = V+Y1 


20 


13 


LI Continue 



//sample computation of V 



It will be appreciate that execution of the pseudocode program instructions shown as lines 
1, 2, and 5 in the above pseudocode segment results in the value of variable R' being 0. 
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Accordingly, the value of flag variable F computed at line 6 in the pseudocode segment results in 

the value of flag variable F being 1 . 

Further disguise may be accomplished by cascading guards. "Cascading" identifies a 

guard installation scheme wherein the program instructions of a first guard compute certain 
5 components used in a second guard. The cascading disguise technique may be used alone or in 

combination with other disguise and guarding technique(s). 

Disguising a guarding scheme by the use of cascading guards can be demonstrated by the 

following example, using the same sample pseudocode segment used elsewhere herein, hi this 

example, identity function I(T1,X1) comprises two sub-functions, S1(T1,X1) and S2(T1,X1), 
10 which have expected values SI true and S2true, respectively. S1(T1,X1) evaluates to SI true if Tl 

== XL S2(T1,X1) evaluates to S2true under the same conditions. Identity function I(T1,X1) 

evaluates to 0 only if Tl = XI, S1(T1,X1) = Sltrue, and S2(T1,X1) = S2true. 

For additional disguise, three more identity functions, I2(x), I3(x), and I4(x), are 

introduced in this example. The identity fimction I2(x) evaluates to 1 for any input x. The 
15 identity function I3(x) evaluates to 0 for any input x. The identity function I4(x) evaluates to 0 

for any input x. Finally, a second flag variable F2 is introduced. The purpose of flag variable F2 

is to record whether this portion of the application software program has been executed. The 

sample pseudocode segment is as follows: i 



20 1 F = 0 

2 Compute XI 

3 Compute X 

4 F=l 
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5 


If (X = TRUE) Go To L 




6 


Take Defensive Action 




7 


L If(F==0)GoToLl 




8 


VI =S1(T1,X1) 


5 


9^ 


V = Z * (A*Z + B) + 72 




10 


V2 = S2(T1,X1) 




11 


Yl =I(V1,V2,T1,X1)*F 




12 


VI = I2(V)*V1 




13 


V = V + Y1 


10 


14 


V2 = I3(Y1) + V2 




15 


V = V + I4(V1) 




16 


F2 = I2(V2) 




17 


LI Continue 



//sample computation of V 



15 Note that even though this pseudocode segment is longer than before, the value of 

program variable V computed by the pseudocode segment is unchanged. 

Cascading of guards arises in this example through the use of the computed values Vl 
and V2 elsewhere in the application software program, but only if the value of flag variable F2 is 
1 (indicating that the preceding pseudocode segment was executed and values VI and V2 were 

20 computed). The computed values of variables VI and V2 then can be compared to the expected 
values SI true and S2true, respectively. The following pseudocode segment illustrates this 
principle: 
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1 




F = 0 


2 




F2 = 0 


3 




Compute XI 


4 




Compute X 


5 




F= 1 


6 




If(X = TRUE)GoToL 


7 




Take Defensive Action 


8 


L 


If(F = 0)GoToLl 


9 




VI =S1(T1,X1) 


10 




V-Z*(A*Z + B) + 72 


11 




V2 = S2(T1,X1) 


12 




Y1=I(V1,V2,T1,X1)*F 


13 




VI =I2(V)*V1 


14 




V = V + Y1 


15 




V2 = I3(Y1) + V2 


16 




V = V + I4(V1) 


17 




F2 = I2(V2) 


18 


LI 


Continue 


19 


L2 


If(F2 = 0)GoToL3 


20 




Y2 = I(Vl,Sltrue) 


21 




V3=Z1 *(A*Z1 +B) + 27 


22 




Y3-I(V2,S2true) 


23 




V3=V3+Y2+Y3 



//sample computation of V 



//sample computation of V3 
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24 L3 Continue 



It is desired in this example to calculate the value of program variable V3 at line 23. Note 
that correct computation of program variable V3 relies in part on the proper execution of the 

5 pseudocode program instructions shown at lines 3, 4, 9, 11, 13, 15, and 17. In turn, the proper 
execution of the pseudocode program instructions shown at lines 3 and 4 depend on the integrity 
of the computation of variables XI and X, respectively. This process can be repeated to further 
entangle the descendents of the guard code with the program code. This further ties the guard 
code to the program as well as aiding in the detection of tampering. 

10 Other program instructions may be interspersed between pseudocode program 

instructions shown above to be adjacent without affecting the output of the pseudocode segment. 
For example, the pseudocode program instruction of line 19 above (identified by label "L2") need 
not be located immediately after the pseudocode program instruction of line 18. Likewise, any of 
the other pseudocode program instructions shown above to be adjacent may, when implemented 

15 as program instructions in a programming language, be separated by one or more other program 
instructions. 

The foregoing example of cascading guards according to the present invention also 
illustrates a feature of the present invention called "code swell." Code swell comprises a process 
for software program disguise comprising replacing a single program instruction with multiple 
20 instructions that provide an equivalent computation. It is a generalization of the idea of a 
mathematical identity to that of a computational identity. 

As discussed previously herein, silent guarding can involve comparing an expected value 
of a variable with the value of the same variable computed at run-time. For example, if an 
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application software program comprises a password p whose value should be 81, a simple silent 
guard according to the present invention may comprise variable t whose value is calculated as 
^[p . Accordingly, the expected value of variable / is computed as ^ - Vsi = 9. Note that only 

the expected value of variable t is stored in the application software program, and not the 
expected value of password p. At run-time, the password p entered by a user of the application 
software program is tested for validity by comparing the expected value of t and the computed 
value . If the password p entered is 81, then / = ^fp = 9, and application software program 

operation proceeds normally. If not, the silent guard comprising variable t takes a defensive 
action. 

An application of code swell to this simple example follows. It is known in the art that 
the following equation is true for any non-negative integer x: 

(x+lf-x^-2x=l 

A practitioner of code swell according to the present invention may substitute variable t 
into the above equation as follows: 

(^+1)^-/^-2^=1 

This equation then may be adapted for the present example by inserting the following 
program instructions into the application software program: 

v = (/+l)^ -t^~lS 

where ^ is a program variable used in the application software program. Note that if /? == , 
81, then V = 1 and the value of program variable x is computed correctly. However, ifp ^ 81, 
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; 

then V 9t 1 . If V ^ 1, the value of program variable x is computed incorrectly, and the program is 
corrupted. The expression x = x * v is an example of a conditional computation. 

The calculation of variable / in this example (i.e., the expression / = ) is performed in 

advance of the code swell (i.e., before the expression v = (^ + 1)^ - - 18). Preferably, the 
5 calculation of variable t is separated from the code swell expression by one or more other 
program instructions so as to hide and camouflage the connection between the silent guard and 
the variable it is guarding. 

Code swell also is useful in a more complex context, where several program variables are 
involved in a much larger code swell. Two program variables are used in this example; x and y, 
10 Program variable y is in current use. It is desired to compute x=y. One example of code swell 
(without guarding) using a computational identify is as follows: 
a, b, c, d are program variables selected arbitrarily 

a\2, a2u «22, V, w are new variables introduced for use in the code swell 
Ci, C2, r\, ri are generated constants where 
15 l<ci,C2<20 

0<r\r2<\ 

The code swell computation is then: 

flu =ci +a + & 
20 ai2 = ri<3^ + (l - rx)b^ 

aix = ric -r2)d 

v = (^ii +^12) 
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' w = (^21 + a22) * y 



Next, the following system of two linear equations is solved for x and y using standard 
codes for Gauss elimination (or Cramer*s Rule): 
flu *x + a\2 * = V 
a2\'^ X + a22* y = w 

If this computation is expressed in 3 -address code, it may transform the simple expression 
X = y into more than 20 program instructions. Further, there may be multiple uses of\the 
variables a, b, c, d and quantities derived from them in the application software program. For 
example, if variable b has an expected value (e.g., it operates as a silent guard variable or a 
checksumming guard checksum), then that value can be substituted into the code swell at some 
point. Thus, if the application software program has been tampered with such that the value of 
the variable b is incorrect, the computation of x is corrupted and the appUcation software 
program fails in a mysterious way. 

The code swell disguise method has at least four beneficial properties to aid in 
tamperproofing. 

• It expands x = y (and similar simple expressions) into a large number of program 
instructions to help disguise the application software program code. 

• It ties several program variables (e.g., a, b, c, d in the above example) into 
computation of variable x to fiirther disguise and protect the application software 
program. This may be especially useful to thwart attack techniques comprising 
variable tracing. 
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• It provides many opportunities for guards. In the above example, it is possible that 
one or more of the variables a, b, c and d could be silent guard variables or 
checksumming guard checksums. 

• There are a huge number of variations of this single code swell so that a practitioner 
5 never has to use the same exact form twice. These variations can be generated 

randomly and automatically by the system of the present invention. 
The CFG of a software program is a static representation of all possible execution flows 
of the software program that may occur during program execution. A statically known and 
structured CFG usually leads to a more accurate analysis and thus a better understanding of the 

10 software program. For example, as discussed by Cifuentes in an article entitled, "Structuring 
Decompiled Graphs," published in Proceedings of the International Conference on Compiler 
Construction, pages 91-105, Linkoping, Sweden, 1996, a structured assembly language software 
program produced from a source code written in a high-level software programming language 
such as C, can be decompiled back to a corresponding C language software program, permitting 

15 better interpretation of the code. In cases where decompilation is impossible, aggressive 
automated software program analysis based on the statically known CFG still is possible using 
methods discussed by Larus in an article entitled, "Whole Program Paths," published in 
SIGPLAN PLDI, May 1999; and by Larus et al. in an article entitled, "EEL: Machine- 
Independent Executable Editing," published in SIGPLAN PI^DI, June 1995. To frustrate 

20 software program analysis and understanding, the CFG must be unstructured and made statically 
unintelligible. 

In addition to a well structured and obvious control flow, assembly language code 
produced by compilers for high-level software programming languages possesses two other 
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disadvantages. The first disadvantage arises from the fact that such assembly language code 
produced by such compilers is very likely to contain many code segments of certain idiomatic 
patterns which may provide hints to understanding the CFG. For example, the GNU GCC 
compiler produces the same segments of code for enclosing each function body: 
5 // entry 



pushl %ebp // save old stack frame pointer 

movl %esp, %ebp // allocate new frame 

subl <const>, %esp // allocate local variables 

10 // exit 

leave // deallocate local vars & frame 

ret // retum to caller 

Similarly, each fiinction call site is coded in another familiar code pattern: 

15 //call site off 

pushl <valuel> // push argl into stack 

pushl <valueN> // push argN into stack 

call f // call the function 

20 add! <4xN>, %esp // restore stack after call 



These patterns expose the functionality of the software program, allowing a hacker to 

dissect the code one subroutine at a time. 

' The second disadvantage of such assembly language code arises from the fact that 

25 assembly language code compiled from high-level source code usually has fixed notation for 

stack variables, for example, base register plus offset. This notation to some degree preserves the 

integrity of corresponding variables in the high-level source code. For example, the assembly 

language code segment below identifies the uses and/or definitions of its variables: 

//b = a*(a + b) 
30 movl -4(%ebp), %eax // %eax := a 

addl -8(%ebp), %eax // %eax := %eax + b 

/ 
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imul -4(%ebp), %eax // %eax %eax * a 
movl %eax, -8(%ebp) // b :^ %eax 



A first, a second, and a third new assembly language software code disguise technique are 

5 disclosed herein. The first new disguise technique is called *'CFG-merging." The second new 
disguise technique is called "CFG-cloning." The third new disguise technique is called "data- 
aliasing." The new disguise techniques will produce unintelligible code and facilitate self- 
protection by: (a) reducing idiomatic code patterns in the code through the use of CFG-merging; 
(b) destroying modularity of subroutines through the use of CFG-merging; (c) creating new, 

10 nondeterministic control flows through the use of CFG-cloning; (d) blurring variable boundaries 
through the use of data-aliasing; (e) concealing constant data values in the assembly language 
code through the use of data-aUasing; and (f) as a result of the foregoing techniques, building a 
network of inter-dependent data values throughout the code, thereby allowing guards to take a 
defensive action due to corruption in any part of the network, the defensive action inducing errors 

15 that are more likely to be global and subtle. 

The first, second, and third new disguise techniques may be used individually. 
Alternatively, any two of the three new disguise techniques may be used in combination. An 
additional alternative may be the use of all three new disguise techniques in combination. 
Repetitive use of the new disguise techniques on the application software program assembly 

20 language code may enhance the level of disguise and protection achieved. One embodiment of 
the code disguise process of the present invention is comprised of discrete applications of the 
three techniques on the code for a certain number of cycles. FIG. 10 shows a flowchart 
illustrating this embodiment of the code disguise process according to the present invention. 
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Techniques of code obfuscation applicable to high-level programming languages such as 
Java and C are known in the art. According to Mambo et aL. techniques of code obfuscation in 
assembly language code remain scarce. The present invention includes three simple yet effective 
code disguise techniques for assembly language software programs, hi addition, these three 

5 techniques can provide guarding capabilities for assembly language software programs. 

Generally, binary executable code or object code may be used as appUcation software 
program code provided the binary executable code or the object code does not base its 
computations on fixed absolute addresses. Nonetheless, if the binary executable code or the 
object code bases its computations on fixed absolute addresses, the binary executable code or the 

10 object code still may be used as appUcation software program code if the binary executable code 
or the object code is converted to a form in which the dependence on the use of fixed absolute 
addresses is eliminated. 

The first assembly language software code disguise technique is called CFG-merging. 
CFG-merging involves changes to the original CFG which force unrelated control flows to 

15 converge, thereby creating merge points at which different data values mix together. FIG. 11 
shows the merging process of two unrelated flows in a simple CFG according to the CFG- 
merging assembly language software code disguise technique of the present invention. From part 
(a) to part (c) of FIG. 11, merging occurs among the ^s andys, respectively. In part (d) of FIG. 
11, merging occurs between the edge from nodes A to y and an internal edge in node D, Pre- 

20 assignments of jump target addresses in the merged nodes are illustrated. The resulting CFG is 
very different from the original. 

CFG-merging works by combining similar intra-block code segments of the assembly 
language software program together. Different code segments are considered "similar" if they are 
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empty code segments that contain no program instructions, or if they are code segments that have 
the same program instructions with same variables in the same order. The variables may have 
the same or different immediate values at corresponding positions. FIG. 12 shows two basic 
blocks being merged according to the CFG-merging assembly language software code disguise 
5 technique of the present invention, wherein the conflicting set of immediate values is replaced by 
a variable initialized to hold the values in the different paths that lead to the same basic block. A 
set or vector of corresponding immediate values, one from each segment, are said to be in 
"conflict" if at least one pair of the values are different. 

The CFG-merging assembly language software code disguise technique of the present 

10 invention consists of a first and a second phase of code merging. In the first phase of code 
merging, similar idiomatic code segments produced by typical compilers are merged. In the 
second phase of code merging, similar segments of the code resulting from the first phase of code 
merging are merged in a randomized manner. 

After multiple iterations of the first and second phase of code merging, the resulting code 

15 and CFG look very different from the original. For example, FIGS. 13A-B shows the sample 
application software program code from FIGS. 7A-B after two code blocks from FIGS. 7A-B 
have been merged. The two code blocks to be merged are the code blocks comprising the first 
four instructions in basic block "main," shown in FIG. 7A as lines 2 through 5, and the first four 
instructions in basic block "pr_fact," shown in FIG. 7A as lines 34 through 37. The first step in 

20 transforming the sample application software program code from FIGS. 7A-B to the merged 
application software program code in FIGS. 13A-B, is to make the candidate code blocks to be 
merged form individual basic blocks by themselves. The basic block "main" is divided into two 
basic blocks, "main l" and "main_2." The basic block "main 1" will contain the first four 
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instructions originally contained in basic block "main," and a new, fifth instruction directing the 
control flow of the application software program to the next basic block to be executed. The 
basic block "main 2" will contain the remaining instructions fi'om basic block "main." 

Similarly, the basic block "pr_fact" is divided into two basic blocks, "pr_fact and 
5 "pr fact l The basic block "pr fact" will contain the first ft)ur instructions originally contained 
in basic block "pr fact," and a new, fifth instruction directing the control flow of the application 
software program to the next basic block to be executed. The basic block "pr fact 1" will 
contain the remaining instructions firom basic block "pr_fact." 

Because each candidate code block to be merged must have at least one predecessor basic 

10 block, a new basic block "main" containing only a trivial jump instruction is created and inserted 
in front of basic block "main_L" Having a predecessor basic block before a merged basic block . 
ensures that data values needed in the merged basic block can be precomputed by the data 
precomputation methods discussed hereinafter before the final binary executable version of the 
merged block is created. The following shows the results of this step: 

15 main: 

jmp mainl 

main l : // a block to be merged 

leal -4(%esp), %esp 
20 movl %ebp, (%esp) 

movl %esp, %ebp 
subl $8,%esp 

jmp main_2 //end of the block 

25 main__2: 

leal -8(%ebp), %eax 

leal -4(%esp), %esp 

movl %eax, (%esp) 

leal -4(%esp), %esp 

30 movl $strl,(%esp) 

A leal -4(%esp), %esp 
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movl Snextl, (%esp) 
jmp scanf 



10 



15 



prfact: 

leal -4(%esp), %esp 

movl %ebp, (%esp) 

movl %esp, %ebp 

subl $4, %esp 

jmp pr_fact_l 

prfaetl : 

// guard installation site 

/ 

movl $100, gl 
movl $next 1 , %eax 



// a block to be merged 



// end of the block 



20 

In the next step, the basic blocks "main 1" and "pr fact" are merged, forming a new basic 
block with the two labels: "main_r' and "pr_fact." The merged basic block initially will contain 
two sets of conflicting constants, which must be resolved for proper execution of the application 

software program. The fourth instruction of the basic block "main_l" uses the constant value 

( 

25 "8," while the fourth instruction of the basic block "pr_fact" uses the constant value "4." The 
fifth instruction of the basic block "main^l" uses the constant value "main_2," while the fifth 
instruction of the basic block "pr fact" uses the constant value "pr_fact_L" The conflicts are 
eliminated by replacing the values "8" and the "4" in the fourth instruction of the merged basic 
block^with the new global variable "g2," and by replacing the values "main_2" and "pr_fact_l" in 

30 the fifth instruction of the merged basic block with the new global variable "g3." 

These new global variables must be initialized by the process of data precomputation so 
they will contain the appropriate value at time of use. In this example, the notation "g2=<8,4>" 
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denotes that variable "g2" must contain the value "8" when the execution flow comes from a 
predecessor of the original basic block "main_l," and that it must contain the value "4" when the 
execution flow comes from a predecessor of the original basic block "pr_fact". Similarly, the 
notation "g3=<main 2,pr_fact_l>" denotes that variable "g3" must contain the value "main_2" 
5 when the execution flow comes from a predecessor of the original basic block "main_l," and that 
it must contain the value "pr_fact 1" when the execution flow comes from a predecessor of the 
original basic block "pr_fact." The following shows the results of this interim step: 
main: 



10 



jmp mainl 



main_l : // the merged block 

pr_fact: 

leal -4(%esp), %esp 

movl %ebp, (%esp) 

15 movl %esp, %ebp 

subl g2, %esp 

jmp *g3 // end of the block 

// g2=<8,4>, g3=<main_2, pr_fact_l> 

20 main_2: 

leal -8(%ebp), %eax 

leal -4(%esp), %esp 

movl %eax, (%esp) 

leal -4(%esp), %esp 

25 movl $strl,(%esp) 

leal -4(%esp), %esp 

movl $next 1 , (%esp) 

jmp scanf 

30 



The next step is to initialize the new global variables by performing data precomputation. 
The application software program code in FIGS. 13A-B shows an example of the finished result 
of the data-precomputations of global variables "g2" and "g3" according to the method of data 
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precomputation discussed hereinafter. As shown in the newly merged basic block in FIG. 13 A, 
an instruction has been modified, and additional instructions have been added to the code so that 
the global variables "g2" and "g3" will contain the proper values at time of use, and so that the 
program execution control flow will proceed correctly. Specifically, the instructions shown in 

5 FIG. 13A on lines 1 1, 13, 14, and 17, have been added to the code. The "jmp" instruction shown 
in FIG. 13A on line 18 has been modified. 

FIGS. 14A-C shows the resulting code after last three instructions of each of the three 
basic blocks "nextl," "main_2," and ".L98" in FIGS. 13A-B have been merged together. The 
newly merged basic block is shown at lines 48-59 of FIGS. 14A-B as the basic block labeled by 

10 "nextl_l," "main_2_l," and ".L98_l The process of merging these three basic blocks generally 
is the same as discussed above. Specifically, each set of instructions to be merged is split from 
its parent basic block into a new basic block. The new basic blocks are merged together. The 
conflicting constants are replaced by new global variables (in this case, gl and g4). Finally, the 
new global variables are initialized by the process of data precomputation. 

15 After each phase of code merging, multiple distinct control flows become coalesced at a 

new fusion point where the different data flows mix together. The resulting CFG usually will be 
a strange-looking graph within which the original execution flows are hidden. The code becomes 
better disguised through additional iterations of the CFG-merging technique. If the code was 
compiled fi-om a high-level source code, it will be difficult for it to be decompiled back to the 

20 source code after merging the code in this manner. 

FIG. 15 shows a diagrammatic example of a CFG with its central portion disguised as a 
result of intensive merging according to the present invention between the two control flows that 
go from AtoD and from B to C, respectively. To a hacker, it is not apparent that the execution 
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flows from A to D. However, the present invention requires that such flow information from the 
original CFG be preserved and known, despite the many rounds of merging that may have 
drastically changed the graph. If such flow information is not preserved, the cost of analyzing 
and disguising the code may grow at an exponential rate. 

5 The present invention uses a simple data structure called a "link-node" to preserve the 

integrity of the original CFG through the code-disguise process. A link-node represents the in- 
flow and out-flow information of a basic block in the original CFG of an application software 
program before CFG-merging. FIG. 16 shows a diagrammatic example of a single link-node 
contained in a basic block of an original CFG according to the present invention. The link-node 

10 maintains the in-flow and out-flow information of the basic block. 

As multiple basic blocks are merged into one new basic block, the link-nodes within the 
old basic blocks are moved to and preserved within the new basic block. FIG. 17 shows a 
diagrammatic example of a process of preserving link-nodes in the new basic block created from 
CFG-merging according to the present invention. Thus, while the CFG changes, its underlying 

15 link-node graph ("LNG") maintains the flow behavior of the original CFG. Throughout the 
process of code disguise, it is the LNG that is being used for supporting data analyses. Note that 
a link-node is contained in exactly one basic block at all times. 

In the context of basic blocks, a basic block "predecessor" of basic block b is defined as a 
basic block that has an out-edge pointing to b. Similarly, in the context of link-nodes, a link- 

20 node "predecessor" of node n is defined as a link-node that has an out-edge pointing to n. "Pred- 
links(x)" is defined as the set of link-node predecessors of link-node x. "Succ-links(x)" is defined 
as the set of link-node successors of fink-node x. 

The following procedure may be used to merge multiple similar code segments together: 
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If a code segment to be merged is not an entire independent basic block, make it 
form an entire independent basic block by splitting it from its parent basic block. 
If a basic block to be merged has no basic block predecessor, for example, if the 
basic block is the starting basic block of the appUcation software program, add an 
empty basic block as its predecessor. 

Among the candidate basic blocks to be merged, select those that satisfy the 
following two conditions: 

(a) Basic blocks that do not contain any link-nodes that share a link-node 
predecessor; 

(b) Basic blocks that do not contain any link-node that is a predecessor of 
itself or of another link-node in either candidate basic block; 

These two conditions make later steps of the merging possible by guaranteeing 
that each distinct link-node in the merged basic bloclc will have a unique, prior 
computation environment for deriving its needed values such as the target 
addresses for the jump instruction. 

Merge the basic blocks into one, collecting and preserving their link-nodes in the 
merged basic block. ^ 
Assign a variable for each conflicting set of immediate values. The chosen 
variable may be either a new or a used variable that is not live in either the link- 
nodes of the merged basic block or in their link-node predecessors. 
Precompute for each of the assigned variables its set of conflicting values.^ 
If any of the basic blocks just merged previously were designated with levels or 
schemes of protection by guards, designate the merged basic block to be protected 
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by the highest level or scheme of protection. This improves the likelihood that the 
merging process will not compromise the levels of protection expected by any of 
the old basic blocks. 

5 Driving the CFG-merging assembly language software code disguise technique, and the 

data-aliasing assembly language software code disguise technique, is a technique called "data 
precomputation." Data precomputation comprises a method of hiding data values in variables 
and precomputing their values before their use. A result of data precomputation is the 
establishment of a network of dynamically changing and mutually dependent data values that is 

10 tightly integrated into the application software program assembly language code. FIG. 18 shows 
a diagrammatic example of such a network. Note that correct execution of the software program 
depends on the values of a variable. If a guard fires during execution, altering the value of at 
least one variable, the error may propagate into other parts of the network and the software 
program potentially may suffer from a subtle error that is difficult for a hacker to detect. 

15 Data precomputation is a general method for precomputing for a variable its set of values 

to be used at different points during the application software program execution, so that upon 
reaching any point during the application software program execution where the variable is to be 
used, the variable will contain an appropriate value. One use of data precomputation is to 
compute multiple sets of conflicting values within a newly merged basic block. 

20 FIGS. 19A-B show an algorithm for performing data precomputation according to the 

present invention. The algorithm illustrated in FIGS. 19A-B performs the data precomputation 
process in a reverse manner by initiating the process from the target basic block and then 
propagating the process in reverse directions of control flows. An advantage of this type of 
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algorithm is that it works systematically with a CFG of any form, and that its backward 
propagation is flexible enough to stop at almost any desired point in the CFG. 

The algorithm illustrated in FIGS. 19A-B begins by setting the expected values of the 
target variable for the link-nodes in the target basic block. Each link-node expects a single value 
5 from the variable. The rest of the process involves "pushing away" the computations of these 
values to other parts of the CFG through the underlying network of link-nodes. 

At each link-node where a variable is expected to hold a certain value, one of the 
following may be used to give the variable its expected yalue: 

1 . Do nothing and pass the same request to all link-node predecessors of the current link- 
10 node; or 

2. Assign the variable its expected value by installing a corresponding computation in the 
parent basic block (if such a computation has not yet been installed), that initializes the 
variable with the value. If the computation uses an uninitialized variable, the variable 
will undergo the same process by requesting the predecessors to initialize it with the 

15 expected value. 

FIG. 20 shows a diagrammatic example of data precomputation based on an underlying 
graph of link-nodes according to the present invention. Part (a) of FIG. 20 illustrates the process 
of backward propagation, starting from the bottom node. Part (b) of FIG. 20 shows what a user 
20 may see given only this portion of the CFG. 

A result of data precomputation is the creation of a global network of inter-dependent 
data values stored as variables upon which the software program host depends. The network of 

inter-dependent data values is sensitive to changes in the data values because a change in one part 

"A 
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of the network may trigger changes in other parts. This enhances the effectiveness of 
checksumming guards in particular, because checksumming guards can fire in one part of the 
network and affect the whole network. As a result, the attacker may see only a consequence of 
checksumming guard firing without knowing where the checksumming guard firing actually 

5 occurs. This effect is called a "subtle errors effect." 

The second assembly language software code disguise technique is called CFG-cloning. 
CFG-cloning compUcates the CFG by adding to it new, seemingly non-deterministic flows. FIG. 
21 shows a diagrammatic example of CFG-cloning according to the present invention, wherein 
basic block / has been cloned from basic block x in FIG. 1 1, so that the flow coming from D' can 

10 go through either of X or nn a randomized maimer. 

CFG-cloning serves as a complement to CFG-merging by introducing into the CFG new 
flows cloned from parts of the graph. The intent of CFG-cloning is to complicate the underlying 
execution flows of the merged CFG by making the new flows that are partial and randomized 
substitutions of their parent flows, injecting "non-deterministism" in execution traces. 

15 Basic blocks are the units to be cloned. The following is a method for CFG-cloning: 



1. 



Selecting a small subset of basic blocks, each of which has a large number of 



unmerged basic block predecessors with only a single link-node successor. 



2. 



Produce a clone for each of the above-mentioned basic blocks. 



3. 



For each newly created clone, direct a subset of its unmerged basic block 



20 



predecessors to also point to it as their new successor. Each of these predecessors 



may be modified in such a way that it will jump to either of its successors based 



on a randomized condition. As an example, one simple way to create a 



randomized condition is to do a comparison between two variables chosen 
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randomly from the code. Outcomes, as a result, are based randomly on run-time 
values of the variables. An application software program with such randomized 
conditions will be more difficult to understand. FIG. 22 shows an example of 
assembly language code containing a randomized jump-based decision which will 
be made by the application software program during program execution based on 
the value of two unrelated variables, %eax and (%esp). 
4. In the final step, all clones undergo basic block rewriting, such as the instruction 
reshuffling and register reallocation techniques used by Mambo et al. Basic block 
rewriting recasts the basic blocks with new looks, thereby offering a plausible 
appearance that they are fiinctionally different from their counterparts. The 
functionality of the basic blocks remains unchanged. These clones may be further 
rewritten by other disguise transformations, such as CFG-merging, in later rounds 
of the code-disguise process. 

The third assembly language software code disguise technique is called data-aliasing. 
Data-aliasing involves hiding data values. In one embodiment, data-aliasing can involve hiding a 
constant data value, such as a numeric literal, in the code. Data-aUasing according to this 
embodiment involves the steps of identifying a constant data value to be hidden, identifying a 
variable, substituting an occurrence of the variable for at least one occurrence of the constant data 
value in the application software code, and initializing the variable by the process of data 
precomputation so that the variable will evaluate to the constant data value when the variable is 
needed during program execution. The steps can be repeated until a desired level of data-aliasing 
is achieved. 
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In another embodiment, data-aliasing can involve creating pointer-aliases with arbitrary 
levels of indirection. FIG. 23 shows a diagrammatic example of data-aliasing according to this 
embodiment, wherein the two occurrences of variable t are aliased by variables tj and t2, which 
are pointers containing the partial address of t, Vciriables t\ and ti contain known precomputed 
5 values, and are used for accessing t indirectly through pointer arithmetic and dereferencing. 
Syntax similar to that used in the C software programming language is used in FIG. 23. 

Data-aliasing is an application of a data-precomputation algorithm to hide data values in 
the code. Based on the network of variables with pre-computed values established by CFG- 
merging, data-aliasing can conceal as many data values in the code as desired, thereby further 
10 weaving the network of inter-dependent values into the host. For example, it can create pointer- 
aliases of arbitrary levels of indirection, by one of the following methods: 

1. If r is a variable whose address, T, is a constant, for example, if ns a global variable, then 
an occurrence of t in the code can be replaced by a mathematical expression which 
evaluates to T, and which is dereferenced. For example, if gi is a new global variable 
15 initialized to hold the mathematical expression (7). Optionally, gj may be initialized to 

hold the value of a mathematical expression comprising Tand at least one numeric literal, 
such as (T - 4340480), or a mathematical expression comprising T and at least one 
variable, such as {T - x), or a mathematical expression comprising T, at least one numeric 
literal, and at least one variable. Where gi has been initialized to hold 7, an occurrence of 
20 t in the code can be replaced by a second mathematical expression, which incorporates g2, 

which evaluates to T, and which is dereferenced, such as, for example, "^{gi)-, where 
denotes pointer-dereferencing. If gi has been initialized to hold a mathematical 
expression comprising T and at least one numeric literal, such as {T - 4340480), then the 
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second mathematical expression substituted for t in this example would be *(4340480^+ 
gi). The second mathematical expression optionally may include additional numeric 
literals and/or at least one additional variable, provided the mathematical expression 
always evaluates to T. The constant address of gi, G2, can in turn be hidden by using 
5 another global variable with a known precomputed value, g\. If g\ holds, for example, 

12345, then the occurrence of g2 in *(4340480 + g2) may be replaced by - K) where 
K is the sum (-G2+12345). The final representation for t then becomes *(4340480+*(gi - 

2. If Ms a stack variable whose address is based on an unknown stack pointer and a known 

f 

10 constant offset, then the constant offset can be disguised in a similar manner to the above. 

The core data precomputation algorithm for data-aliasing is the same as that used in CFG- 
merging, except that in the data-aliasing technique the algorithm takes in only a single data value 
to be precomputed instead of a vector of them. The technique of data-aliasing involves randomly 
and repetitively selecting a subset of data values in the code and then performing data 

1 5 precomputation for each of them. 

It is known by those of ordinary skill in the art to provide the ability to insert different 
watermarks or fingerprints in otherwise identical copies of an application software program. For 
simplicity, the term "watermark" as used in the following discussion includes both software 
"watermarks" and software "fingerprints." ^ Therefore, a watermark "PT/" in one copy of an 

20 application software program (denoted as "iS'y") is different fi-om a watermark in another 
copy of the application software program (denoted as "82")^ Preferably, program copies Sj and S2 
operate identically, even though each contains a different watermark. 
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Software ^yatermarks are messages encoded into software programs. Software' 
watermarks often carry information, such as information identifying the licensee or the vendor of 
the software program. A tamper-resistant watermark makes software program piracy less likely, 
since the watermark can be used to prove ownership of a software program copy, as well as to 
5 trace the origin of illegal redistribution of a software program. In addition to tamper-resistance, 
salient features of software watermarks include sufficient data capacity for encoding messages, 
ease of extraction by software program vendors or authors, and a high degree of confidentiality 
for sensitive messages. 

With SPC, all of the foregoing sahent features of software watermarking are attainable. 

10 To become tamper-resistant, watermarks are inserted into inter-basic block regions of the 
application software program that have been protected by checksumming guards. Unlike 
dynamic watermarking schemes disclosed by CoUberg et al. in an article entitled, "Software 
Watermarking: Models and Dynamic Embeddings," published in ACM SIGPLAN-SIGACT 
POPL'99, San Antonio, Texas, USA, Jan. 1999, in which watermarks are encoded in run-time 

15 data structures and where data capacity becomes an issue, the watermarking or fingerprinting 
scheme of the present invention is static in nature and, theoretically, is unlimited in data capacity, 
hi practice, however, longer watermarks may shghtly degrade software program performance. 
Fxuthermore, as with any static watermarking scheme, extraction of watermarks is easily 
accomplished by scanning the file for known messages or patterns. 

20 If confidentiality is necessary, watermarks can be encrypted before they are inserted into 

the code. The following is an example of a scheme for producing encrypted watermarks that 
appear to be random byte strings, even if the watermark messages have the same contents. Each 
watermark message is encoded into a sequence of byte strings as shown in FIG. 24. In FIG. 24, 
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tag is a one-byte prefix common to all watermarks in the code. This one-byte prefix may be 
specified by the user, or may be derived from encryption key by a means known in the art, such 
as, for example, from the application of a one-way hash function to the encryption key or to a 
character string containing the encryption key, or from a random number generator whose seed is 
5 the encryption key. With only one byte, the tag effectively limits the search space for true 
^ watermarks without compromising its random-looking appearance. Li FIG. 24, shfisz two-byte 
number that is unique for each of the watermarks, \yhich may be extended to be four-bytes long if 
a large number of watermarks are to be encrypted.. It is this number that gives messages of same 
content different appearances, by first masking their content and length using the same number 

10 (denoted as ''msg -^shf" and "len + shf) before they are encrypted, In FIG, 24, E(M) denotes an 
encrypted version of string M using public key £{•). E(M) can be decrypted only by using a 
secret key known only to the party who encrypted the message. 

Because a watermark W often comprises sensitive information, it may be desirable to 
protect the watermark W with a network of guards. It also may be desirable to use the same 

15 network of guards in each copy Sy (where y is an integer index variable and 1 < j;) of the 
application software program 5. However, in a case where, for example, copies Sj and S2 of 
application software program S comprise watermarks Wi and W2, respectively, use of the same 
network of guards makes appUcation program S susceptible to a collusion attack, wherein 
program copies Sj and S2 are compared instruction-by-instruction. 

20 For example, if any two program copies Sj and S2 comprise the same network of guards 

M comprising checksumming guards Gi,..,,Gm (2 < m), wherein (1) the client code of each 
checksumming guard G/ (where i is an integer index variable and 2 < i < m) comprises 
checksumming guard G/./, (2) the client code block of checksumming guard Gy in program copy 
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Sj comprises watermark Wj, and (3) the client code block of checksumming guard G/ in program 
copy S2 comprises watermark W2, then the expected checksum of the cHent code block 
comprising watermark Wi appears in or is accessed by checksumming guard Gj of program copy 
Sj, and the expected checksum of the client code block comprising watermark W2 appears in or is 
accessed by checksumming guard Gj of program copy 82^ Likewise, the expected checksum of 
the client code block comprising checksumming guard Gj of each program copy Sy appears in or 
is accessed by checksumming guard G2 in each program copy Sy, and the expected checksum of 
the client code block comprising checksumming guard G2 in each program copy Sy appears in or 
is accessed by checksumming guard G3 in each program copy *S^, and so on until reaching 
checksumming guard G^. 

Checksumming guard G/ in program copy Sj is not the same as checksumming guard Gj 
in program copy S2, because checksumming guard Gj comprises information about the expected 
checksum of the client code block comprising watermark Wj or W2 (respectively). Likewise, 
checksunmiing guards G2 through Gm in program copy Sj are not the same as their counterpart 

checksumming guards G2 through Gm in program copy S2. Thus, a comparison of program 

f'' 

copies S/ and S2 (such as in a collusion attack) reveals not only the differences in watermarks W/ 
and W2, but also the differences between the checksunmiing guards G, of program copy Si and 
the checksumming guards G/ of program copy S2* A practitioner can end, up with every 
checksumming guard G, depending in some manner on watermark Wy, and thus every 
checksumming guard G/ will look different for each copy Sy of the application software program 
S. 

The present invention comprises a method for using guards to protect differently 
watermarked copies of an application software program, wherein an application software 
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program so protected is made less susceptible to a collusion attack. According to the present 
invention, a collusion attack of the type discussed above may be thwarted by "decoupling" 
checksumming guards G/ from watermark Wy in each program copy Sy. Thus, according to the 
present invention, in a network of guards M comprising m checksumming guards d (where 1 < / 
5 < m; 2 < m), wherein checksumming guard Gj protects the integrity of watermark Wy and 
checksumming guards G^, ...,G„, protect each other and checksumming guard G/, the network of 
checksumming guards M appears to be identical in each copy Sy of application software program 

Watermark Wy is an integer according to this method. The value of watermark Wy must 
10 be greater than 1. Preferably, watermark Wy has a large value and a length of not less than 128 
bits, but this is not required. Wy is stored program copy Sy. 

In a first embodiment of this method, new constant integers Ay and V are introduced. V is 
a randomly selected integer, but its value is the same in all differently watermarked copies Sy of 
application software program S, Vis stored in the program code of all program copies Sy. 
15 The value of constant Ay is equal to the difference between integer V and watermark Wy, 

Accordingly, constant Ay is different in all differently watermarked copies Sy of application 
software program iS. In equation form: 

Ay=V'Wy 

Also introduced in this embodiment is a decoupling guard designated as guard Go* Guard 
20 Go is installed in program copy Sy after watermark Wy and integers Ay and. Fare installed. Guard 
Go is inserted into network of guards M such that the client code block of guard Go comprises 
watermark Wy, and the client code block of checksumming guard G; comprises guard Go. 
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Guard Go comprises properties that are different from those of checksumming guards 
Gy, .,.,Gni. hi operation, when the appUcation software program instructions comprising guard Go 
are executed, instead of calculating the checksum of its chent code block comprising watermark 
Wy, guard Go merely verifies that watermark Wy is of the expected length, and then computes the 
sum of watermark Wy and constant integer Ay and performs a conditional computation to verify 
that the result is equal to V, Thus, V is part of guard Go and is therefore protected by the guard(s) 
that protect guard Gq, If watermark Wy has been altered after constant integer Ay is calculated and 
stored in program copy Sy, the conditional computation comprising the following equation will 
not hold true: 

Wy+Ay=^V 

Guard Go then will take a defensive action. 

Checksumming guard Gj computes the checksum of a client code block comprising guard 
Go, rather than a client code block comprising watermark Wy. The operation of each other 
checksumming guard G, (namely, checksumming guards G2, ...,G;„) is unaltered. Each computes 
the checksum of the client code block comprising guard G/_y. 

Because V is the same in all differently watermarked copies Sy of application software 
program 5, guard Go looks the same in all differently watermarked copies Sy. Because guard Go 
appears to be the same in all Sy, so does checksumming guard Gj and, hence, so do all of the 
other checksumming guards G, of network of guards M Accordingly, a collusion attack against 
two differently watermarked copies Sy of application software program S exposes only the 
different watermarks Wy, but does not expose any of the guards G/. An attacker unaware of the 
network of guards may attempt to alter a watermark Wy, but in so doing will cause one or more of 
the guards G, to take a defensive action. 
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Although this first embodiment of the method for using guards to protect differently 
watermarked copies of an application software program can be effective, the protection afforded 
to application software program S by this first embodiment is weak because of the simple 
expression used to compute Ay, A collusion attack on differently watermarked program copies Sj 
5 and S2 will reveal watermarks W/ and W2, respectively. Also revealed will be constants Aj and 
A2, respectively, which are different in program copies Si and 1S2. A hacker thereafter can 
replace, for example, watermark Wj with a forged watermark Wjf, and concurrently replace 
constant ^/ with the result of F - Wjf. Thus, guard Go in program copy Sj still obtains constant F, 
even though watermark Wj was replaced with forged watermark Wjf, 

10 Another, more resilient embodiment of the method for using guards to protect differently 

watermarked copies of an application software program also uses a randomly selected constant 
integer V which has the same value in all differently watermarked copies Sy of application 
software program ^S*. Also used in this embodiment is decoupling guard Go, which is installed in 
the network of guards M such that the client code block of guard Go comprises watermark Wy, 

15 and the client code block of checksumming guard Gj comprises guard Go- 

' hitegers Py and qy are introduced used in this embodiment. Each of integers py and qy has 
a predetermined and constant value. Integers py and qy are associated with each program copy Sy,; 
but are not stored within the code comprising the program copy Sy. However, the multiplicative 
product pyqy of integer py and integer qy is stored within the code comprising the program copy 

20 Sy, According to this embodiment, each integer py and integer qy comprises the following 
properties: 

• Each is a prime number 
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• py modulo V^O 

• r modulo /j^; 9^0 

• qy modulo 0 

• F modulo qry^p^O 

5 • V<Pyqy 

I 

Integers py and qy are selected so that it is difficult for an attacker to derive integers py and 
qy from multiplicative product pyqy. In an embodiment, integers py and qy are large numbers. 

A one-way function of the type discussed previously herein (denoted as "H{*)") is used in 
this embodiment. One-way function //(•) is executed with unaltered watermark Wy as its input 
10 argument. According to this embodiment, each one-way function H(Wy) has a multiplicative 
inverse modulo (py - l){qy - 1). The multiplicative inverse of one-way function H(Wy) modulo (py 
- l)iqy - 1) is represented hereinafter by and satisfies the equation: 

Wy * H(Wy) modulo (py - l)(qy - 1) = 1 
Multiplicative inverse Wy is computed as part of process of installing watermark Wy in 
15 the application software program, but it is not stored within the code comprising program copy 
Sy. Integer (py - 1), integer (qy - 1), and multiplicative product (py - l)iqy - 1) also are not stored 
within the code comprising the program copy Sy. A practitioner of the present invention is 
advised that, to ensure that a multiplicative inverse W'y exists in every case, the values of py and 
qy are selected so that for a given one-way function H(Wy) there is a multiplicative inverse W*y 
20 which satisfies the above-defined equation. In an implementation of the present invention, 
random values of integer py and qy are tested until a set of py and qy is found which satisfies the 
above-defined equation. 
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Also according to this embodiment, a new constant integer Qy is introduced. The value of 
constant Qy is calculated according to the following equation: ^ 

Qy = V^'^ modulo pyqy 

As part of process of installing guard Go in the appHcation software program copy Sy,(l) 
5 integer V is identified, (2) integers py and qy are selected and multiplicative product pyqy is 
computed, (3) watermark Wy is identified, (4) one-way function H(Wy) is computed, (5) 
multiplicative inverse W*y is computed, and (6) integer Qy is computed. Recall that integers Py 
and qy and multiplicative inverse W*y are not retained anywhere in the application software 
program after integer Qy is computed. 
10 As in the first embodiment of this method, guard Go /in this embodiment comprises 

properties that are different from those of checksumming guards G/, ...,Gm. histead of calculating 
the checksum of its cUent code block comprising watermark Wy, guard Go performs a conditional 
computation to verify that the result of raising Qy to the power of one-way function H(Wy) 
modulo Pyqy is equal to V. \n equation form:' \ 
15 Qy^^^'^ modulo Pyqy =V 

This equation is true because: 

Qy"^^'^ modulo Pyqy = {f'y modulo p^yf^^'^ modulo pyqy 

and 

(J^'^ modulo p^yf^^'^ modulo pyqy - V 
20 Recall that the value of multiplicative inverse Wy does not appear anywhere in program 

copy Sy of application software program S. Multiplicative inverse Wy is shown in the above 
equations only to explain the operation of the Q^^^^^ modulo pyqy = F equation. 
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If watennark Wy has been altered after constant Qy is calculated and stored in the program 
code comprising program copy Sy^ the conditional computation comprising the equation: 

Qy^^^'^ modulo pyq^=V 
will fail. Guard Go will take a defensive action. 

According to this embodiment, checksumming guard Gj computes the checksum of a 
cUent code block comprising guard Go, rather than a client code block comprising watermark Wy. 
The operation of each other checksumming guard G/ (namely, checksumming guards G2,...,Gm) 
is unaltered. Each computes the checksum of the client code block comprising guard G/./. 

Because V is the same in all differently watermarked copies Sy of application software 
program guard Gq appears to be the same in all *S^, and hence so do all other guards G,. 
Accordingly, a collusion attack against two differently watermarked copies Sy of application 
software program S exposes only the different watermarks Wy and constants Qy, but does not 
expose any of the checksumming guards G/. An attacker unaware of the network of guards may 
attempt to alter a watermark Wy, but in so doing will cause one of more of the guards G, to take a 
defensive action. 

The fact that integers py and qy are not apparent (and preferably not known) to an attacker 
makes it difficult for the attacker to modify a watermark Wy and perform a corresponding 
modification to constant Qy that maintains the Qy^^^^^ modulo pyqy = F property. A modification 
to a watermark Wy after constant Qy is calculated and stored in program copy Sy, is detectable by 
guard Go unless such a corresponding modification is made to constant Qy, Modifying constant 
Qy requires computing a new multipUcative inverse (modulo (py - l)(qy ^ 1)) of one-way function 
H(Wy), which is difficult to carry out without knowing integers py, qy, (py- 1), and/or (qy - 1). 
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Accordingly, protection of watermark Wy is stronger in this embodiment than in the first previous 
embodiment. 

Yet another embodiment of this method for using guards to protect differently 
watermarked copies of an application software program uses an asymmetric key encryption 
5 technique of a type known in the art comprising a public-private key pair. As used elsewhere 
herein, £{•) denotes the public key, and D{*) denotes the private key. A one-way function //(•) of 
the type discussed previously herein also is used. Public key and one-way function //(•) are 
stored in program copy Sy. Preferably, private key /)(•) is not stored anywhere within program 
copy Sy. 

10 This embodiment uses decouphng guard Go. As before, the client code block of guard Go 

comprises watermark Wy, and the client code block of checksumming guard Gj comprises guard 
Go. Constant integer Qy is adapted for use in this embodiment. The value of constant Qy in this 
embodiment is computed by executing one-way function //(•) with watermark Wy as its input 
argument, and then encrypting the result of one-way function //(•) using private key D(*), In 

15 equation form: 

Qy-D(H(W,)) 

Integer Qy is computed as part of process of installing guard Go in the application 
software program. Integer Qy then is stored as a constant within the code comprising program 
copy Sy, 

20 Guard Go comprises properties which are different from those of checksumming guards 

Gu Instead of calculating the checksum of its cUent code block comprising watermark Wy^ 

during program execution guard Go executes one-way function //(•) with watermark Wy as its 
input argument, decrypts Qy using public key E{*)^ and then performs a conditional computation 
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to verify that the computed values are the same. In equation form, guard Go performs a 
conditional computation to verify that the following property is present: 

H(Wy)=E(Qy) 

If watermark Wy has been altered after constant Qy is calculated and stored in the program 
5 code comprising program copy Syy the conditional computation will fail. Guard Go will take a 
defensive action. 

The remaining operation of network of guards M is in accordance with the operation 
described previously herein in regard to the earlier embodiments. Specifically, checksumming 
guard Gj computes the checksum of a client code block comprising guard Go, rather than a client 

10 code block comprising watermark Wy, Because guard Go appears to be the same in all Sy, so does 
checksumming guard Gj and hence so do all of the other guards G/ of the network of guards M 
Accordingly, a collusion attack against two differently watermarked copies iS^ of application 
software program S exposes only the different watermarks Wy and constants Qy, but does not 
expose any of the guards G,. An attacker unaware of the network of guards may attempt to alter 

15 a watermark Wy, but in so doing will cause one or more of the guards Gi to take a defensive 
action. 

In this third embodiment of the method for using checksumming guards to protect 
differently watermarked copies of an application software program, it is essential to compute Qy 
using one-way function //(•) with watermark Wy as its input argument. Absent the use of one- 
20 way function //(•), the value of constant Qy would be set equal to D{Wy) instead of D(H(Wy)). 
Under these conditions, guard Go would verify the following property: 

Wy-E(Qy) 

instead of 
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H(Wy)=E(Qy) 

A problem arises if the conditional computation of guard Go verifies Wy = E(Qy). 
Because both constant Qy and public key E{*) are present in the program copy Sy, a savvy hacker 
easily could replace Qy in a program copy Sy with a random number r, and concurrently replace 

5 watermark Wy in the program copy Sy with E{r). Thus, guard Go would, in effect, be verifying 
that E{r) = £(r). Although watermark Wy has been altered (i.e., replaced by E{r)\ the conditional 
computation would not fail, giving the appearance that watermark Wy is authentic. 

Using one-way function H{^) M^ith watermark Wy as its input argument avoids this 
shortcoming, because it becomes very difficult to change watermark Wy (such as by replacing it 

10 with a decrypted random number E{r)) and make a corresponding change to Qy that maintains the 
H(Wy) = E(Qy) property. Because of the inherent one-way property of one-way function //(•), 
there is not a direct relationship between changes to watermark Wy and changes to H(Wy). 
Accordingly, because Qy is calculated using H(Wy), there is not a direct relationship between 
changes to watermark Wy and changes to Qy, 

15 Each of the foregoing embodiments of the method for using guards to protect differently 

watermarked copies of an application software program is described in terms of an acyclic guard 
formation. However, the same result can be achieved from each of these embodiments regardless 
of whether the network of guards comprises an acyclic guard formation, a cyclic guard formation, 
or a polycyclic guard formation. 

20 It is known by those of ordinary skill in the art to provide the ability to insert one or more 

program parameters into copies of an application software program. These program parameters 
may be different in otherwise identical copies of an application software program. Such program 
parameters may, for example, implement software license restrictions or govern the allowed 
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modes of use of the application software program. Thus, a first end user having a first copy S/ of 
application software program S comprising a first set of program parameters Pj may have the 
ability to use features of the application software program which are different from the features 
available to a second end user having a second copy S2 of application software program S 

5 comprising a second set of program parameters 

Individual program parameters may be "independent," meaning that the presence of or 
value of a first program parameter in a copy of an application software program does not 
correlate to the presence of or value oiF a second program parameter in the same copy. 
Alternatively, two or more program parameters may be "related" in a copy of an application 

10 software program such that the presence of or value of a first program parameter in a copy of an 
application software program correlates to the presence of or value of a second program 
parameter in the same copy. An application software program may comprise certain program } 
parameters which are independent, and other program parameters which are related, hi an 
embodiment, one or more of the program parameters may comprise a watermark. 

15 Where the application software program is acquired by an end user through a download 

fi-om a server to the end user's computer, the program parameters may be set by the server at 
software download time. Where the application software program is purchased on a computer 
readable medium such as a CD-ROM, the program parameters may Jbe encoded into the 
application software program code on the CD-ROM. Li an embodiment, a software publisher 

20 may adjust the set of program parameters according to the price an end user pays for the 
application software program. Thus, a first end user paying a higher price may receive a copy of 
the program comprising a set of program parameters allowing access to more ifeatures of the 
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program. Conversely, a second end user paying a lower price may receive a copy of the program 
comprising a set of program parameters allowing access to fewer features of the program. 

As with watermarks, problems may arise if one or^more program parameters are 
discovered and altered by a hacker. The hacker may be able to obtain and use features of the 
5 application software program which exceed those to which the hacker otherwise would be 
entitled. In addition, a hacker, having overridden a program parameter limitation in an 
, application software program, may distribute copies of the altered program to others, or may 

r 

publicize his method for overriding the program parameter to permit others to alter the 
application software program in the same way. 

10 Accordingly, in a copy Sy of an application software program S, it is desirable to protect 

the program parameters Zj in the set of program parameters Py (where j and y are integer index 
variables; I <j;\ <y) with one or more guards, or with a network of guards.. In addition, where 
the application software program comprises a plurality of program parameters, it is desirable to 
have the plurality of program parameters rely on each other for protection, even if such program 

15 parameters are otherwise independent. 

If a network of guards is to be used, it may be desirable to use the same network lof guards 
in each copy Sy of the application software program S, However, as was the case with 
watermarks, in the event copies Sj and S2 of application software program S comprise sets of 
program parameters Pj and P2, respectively, use of the same network of guards makes 

20 application program ^S" susceptible to a collusion attack, wherein program copies Sj and S2 are 
compared instruction-by-instruction. For the reasons discussed previously herein in regard to 
protecting differently watermarked copies of an application software program, a collusion attack 
may reveal not only the program parameters Zj, but also all guards in network of guards . 
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The present invention comprises a method for creating mutually reliant program 
parameters. According to the method of the present invention, a plurality of program parameters 
Zj are associated in a way that reduces the likelihood that any particular program parameter Zy can 
be altered unexpectedly without disrupting proper execution of the program copy Sy. The method 
5 for creating mutually reliant program parameters according to the present invention comprises an 
adaptation of the method described above regarding the use of guards to protect differently 
watermarked copies of an application software program. Also according to the method of the 
present invention, the same network of guards can be used in all copies Sy of application software 
program S, 

10 The method for creating mutually reliant program parameters of the present invention can 

be illustrated by an example where an application software program S comprises a set of program 
parameters P, which comprises n program parameters Zy,...,Z;, (where 2 ^ n). Program copy Si 
comprises set of program parameters Py, and program copy S2 comprises set of program 
parameters P2- At least one program parameter Zj has a value which is not the same in both sets 

15 of program parameters Pi and P2- 

According to this method, all program parameters Zj (where 1 <y < w) in a program copy 
Sy are concatenated to form a constant Uy, The order in which the program parameters Z, appear 
in concatenated constant Uy is left to the discretion of the practitioner. Constant Uy then is 
protected by a network of guards M comprising guards Gi {i is an integer index variable; 0 < / < 

20 m) in a manner similar to the manner by which watermark Wy was protected in the method for 
watermark protection according to the present invention previously discussed herein. 

In a first embodiment of the method for creating mutually reliant program parameters, 
constant integers Ay and V are used. Each has properties which are the same as those discussed 
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above in regard to the first embodiment of the watermark protection method of the present 
invention. F is a randomly selected integer having the same value in all copies Sy of appUcation 
software program S, and is stored in the program code of all program copies Sy, Constant Ay is 
equal to the difference between constant Fand constant Uy. Accordingly, constant is different 

5 in all copies Sy of application software program S, 

After constant Uy and integers Ay and V are installed in program copy Sy, guard Go is 
installed in network of guards M, The client code block of guard Go comprises constant Uy. 
Guard Gj has a client code block comprising guard Go. Each of guards Gz.^^^.Gm has a client 
code block comprising guard G/.y. Guards Gi,,,,,Gni are checksumming guards. In operation, 

10 when the application software program instructions comprising checksumming guard Go are 
executed, guard Go recreates constant Uy by "re-concatenating" program parameters Z]^...,Zn, 
then computes the sum of recreated constant Uy and constant integer Ay, and performs a 
conditional computation to verify that the result is equal to K Constant integer V is part of the 
program instructions comprising guard Go- Thus, it is protected by the network of guards M. 

15 If one or more program parameters Zj has been altered after constant integer Ay is 

calculated and stored in program copy Sy, the sum of constant integer Ay and recreated constant 
Uy (comprising the altered program parameter(s) Zj) will not equal V, The conditional 
computation comprising the equation Uy Ay= V will not hold true, and guard Go will take a 
defensive action. Because Fis the same in all copies Sy of appUcation software program S, guard 

20 Go looks the same in all program copies Sy, as do the other checksumming guards Gi,.,.,Gm' 

Although this first embodiment of the method for creating mutually reliant program 
parameters in an appUcation software program can be effective, the protection afforded to 
application software program S by this first embodiment is weak because of the simple formula 
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used to compute Ay. A collusion attack on differently watermarked program copies Sj and S2 will 
reveal constants Uj and C/?, respectively. Also revealed will be constants ^4; mdA2, respectively, 
which are different in program copies Sj and 82^ A hacker thereafter can replace, for example, 
constant Uj with a dummy constant Ujd, and concurrently replace constant ^4/ with the result of V 
5 - U}(i, Thus, guard Go in program copy Sj still obtains constant V, even though constant Uj was 
replaced with dummy constant U/d- 

In another embodiment of the method for creating mutually reliant program parameters, 
randomly selected constant integer V is used again, as is guard Go, which again has a client code 
block comprising constant Uy. Constant integers py and qy are used, each having properties 

10 which are the same as those discussed above in regard to the second embodiment of the 
watermark protection method of the present invention, hategers py and qy are associated with 
each program copy Sy, but are not stored within the code comprising the program copy *S^. The 
multiplicative product pyqy of integer py and integer qy is stored within the code comprising the 
program copy Sy, A one-way function //(•) of the type discussed previously herein also is used in 

15 this embodiment. 

One-way function //(•) is executed with unaltered constant Uy as its input argument. 
According to this embodiment, each one-way function H(Uy) has a multiphcative inverse modulo 
(Py - ^)i^y -1)- The multiplicative inverse of one-way function H{Uy) modulo (py - l){qy - 1) is 
represented hereinafter by "C/^," and satisfies the equation: 

20 U'y * H{Uy) modulo (py - l)(qy - 1) = 1 

Integer (py - 1), integer (qy - 1), and multiplicative product (py - l)(qy - 1) are not stored 
within the code comprising the program copy Sy. A practitioner of the present invention is 
advised that, to ensure that a multiplicative inverse Uy exists in every case, the values of py and 

P00620-US-01 121 



qy are selected so that for a given value of constant Uy there is a multiplicative inverse U*y which 
satisfies the above-defined equation. In an implementation of the present invention, random 
values of integer py and qy are tested until a set ofpy and qy is found which satisfies the above- 
defined equation. 

Also according to this embodiment, constant Qy is used. The value of constant Qy is 
calculated according to the following equation: 

Qy-^V^y modulo PyQy 

As part of process of instaUing guard Go in the application software program copy Sy, (1) 
integer V is identified, (2) integers py and qy are selected and multiplicative product pyqy is 
computed, (3) watermark Uy is identified, (4) one-way fimction H(Uy) is computed, (5) 
multiplicative inverse U'y is computed, and (6) integer Qy is computed. Recall that integers py 
and qy and multiplicative inverse U*y are not retained anywhere in the application software 
program after integer Qy is computed. 

In operation, guard Go recreates constant Uy by "re-concatenating" program parameters 
Zy,. . .,Z„, and then performs a conditional computation to verify that the result of raising Qy to the 
power of one-way function H(Uy) modulo pyqy is equal to V, In equation form, guard Go 
performs a conditional computation to verify that the following property exists: 

Qy"^^'^moA\x\opyqy^ V 

If one or more program parameters Zj has been altered after constant Qy is calculateid and 
stored in the program code comprising program copy Sy, the conditional computation comprising 
the foregoing equation will fail. This is because constant Qy is calculated using the 
multiplicative inverse Uy of one-way function H(Uy), If one or more program parameters Zy has 
been altered, recreated constant Uy will not be the same as original constant Uy, Thus, 
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multiplicative inverse U*y (of the one-way function H{*) with original constant Uy as its input 
argument) and the one-way function //(•) with recreated constant Uy as its input argument will 
not cancel each other, as is necessary for the above equation to hold true. Accordingly, guard Go 
will take a defensive action. 

5 The fact that integers py and qy are not known to and not readily discoverable by an 

attacker makes it difficult for the attacker to modify any program parameter Zj which comprises 
constant Uy and then perform a corresponding modification to constant Qy that maintains the 
Qy^^^y^ modulo pyqy = F property. A modification to any program parameter Zj after constant Qy 
is calculated means that the value of original constant Uy used to calculate constant Qy will be 

10 different fi*om the value of constant Uy recreated during program execution. Thus, a modification 
to any program parameter Zy is detectable by guard Go unless a corresponding modification is 
concurrently made to constant Qy, Modifying constant Qy requires computing a new 
multipUcative inverse (modulo {py - \){qy - 1)) of the one-way function //(•) with recreated 
constant Uy as its input argument, which is difficult to carry out without knowing integers py, qy, 

15 {py - 1), and/or {qy - \)[ 

A third embodiment of the method for creating mutually reUant program parameters uses 
asymmetric key encryption technique of a type known in the art comprising a public-private key 
pair. As before, £(•) denotes the public key, and D{*) denotes the private key. A one-way 
function //(•) of the type discussed previously herein also is used. Public key £{•) and one-way 

20 function //(•) are stored in program copy Sy. Private key £)(•) is not stored anywhere within 
program copy iSj;. 

This embodiment also uses guard which has a client code block comprising constant 
Uy, Constant integer Qy is adapted for use in this embodiment. The value of constant Qy in this 
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embodiinent is computed by executing one-way function //(•) with constant Uy as its input 
argument, and then encrypting the result of one-way function //(•) using private key !)(•). , In 
equation form: 

Qy^D(H(Uy)) 

5 Integer Q is computed as part of process of installing guard Go in the application software 

program. Integer Q then is stored as a constant within the code comprising program copy Sy. 

In operation, guard Go recreates constant Uy by "re-concatenating" program parameters 
Ziy,,,^Zn, executes one-way function H{*) with recreated constant L(y as its input argument, 
decrypts Qy using public key and then performs a conditional computation to verify that the 

10 computed values are the same. In equation form, guard Go performs a conditional computation 
to verify that the following property is present: 

H(Uy)^E(Qy) 

If one or more program parameters Z, has been altered after constant Qy is calculated and 
stored in the program code comprising program copy 5^, the conditional computation comprising 

15 the foregoing equation will fail. This is because constant Qy is calculated using a one-way 
function //(•) with original constant Uy as its input argument, and then encrypting the result of 
one-way function //(•) using private key £)(•). Decrypting constant Qy with public key £(•) 
during the conditional computation returns the value of one-way function //(•) with original 
constant Uy as its input argument. If one or more program parameters Zj has been altered, 

20 recreated constant Uy will not be the same as original constant C/^;. Thus, the result of one-way 
function H{^) with recreated constant Uy as its input argument will not be the same the result of 
one-way function //(•) with original constant Uy as its input argument, as is necessary for a 
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conditional computation comprising the above equation to hold true. Accordingly, guard Go will 
take a defensive action. 

The fact that private key D(*) is not known or readily discoverable by an attacker makes it 
difficult for the attacker to modify any program parameter Zj and then perform a corresponding 
5 modification to constant Qy that maintains the H(Uy) = E(Qy) property. A modification to any 
program parameter Zj after constant Qy is calculated means that the value of original constant Uy 
used to calculate constant Qy will be different fi"om the value of constant Uy recreated during 
program execution. Thus, a modification to any program parameter 2) is detectable by guard Go 
unless a corresponding modification is concurrently made to constant Qy. Modifying constant Qy 

10 requires executing one-way function //(•) with recreated constant Uy as its input argument, and 
then encrypting the result of one-way function H{^) using private key Z)(*), which is difficult to 
carry out without knowing private key />(•). 

The remaining operation of network of guards M in each embodiment of the method for 
creating mutually reliant program parameters is the same. Checksumming guard Gy computes 

15 the checksum of a chent code block comprising guard Gq, checksumming guard G2 computes the 
checksum of a client code block comprising checksumming guard G/, and so on. Because guard 
Go appears to be the same in all Sy, so does checksumming guard Gj and hence so do all of the 
other guards d of the network of guards M. Accordingly, a collusion attack against two copies 
Sy of application software program S exposes only the different program parameters Zj, constants 

20 By, and constants Qy, but does not expose any of the guards G/. An attacker unaware of the 
network of guards may attempt to alter program parameter Z), but in so doing will cause one of 
more of the guards G/ to take a defensive action. 
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Each of the foregoing embodiments of the method for creating mutually reliant program 
parameters in an application software program is described in terms of an acyclic guard 
formation. However, the same result can be achieved from each of these embodiments regardless 
of whether the network of checksumming guards comprises an acyclic guard formation, a cycUc 
5 guard formation, or a polycyclic guard formation. 

Given that directly attacking some highly guarded application software program code is 
difficult, there is a type of attack that could easily bypass the guards by attacking the "neighbors*\ 
of the guarded code instead. This type of attack is called "clone attack," in which clones of the 
code blocks are first produced, then compromised, and finally merged into the application 

r 
I 

10 software program code, substituting for the original target code blocks, which are left intact but 
no longer execute during program execution. 

FIG. 25 shows a diagrammatic example of a clone attack. In FIG. 25, the attack target, 
basic block B2, is highly protected but its predecessor, basic block Bi, is not protected at all. In 
this case, an attacker can easily produce basic block B 2, a clone of basic block B2, as an 

15 extension of the program. Basic block B 2 then becomes the attack target without any protection. 
To make the compromised basic block B 2 a part of execution, the hacker redirects the transfer of 
control from basic block Bi to flow into basic block B 2, which then reroutes the flow back to 
basic blocks B3 and B4. The example above states the fact that a checksumming guard protection 
scheme can be bypassed easily if the protection range misses the "weak points" in its control- 

20 flow predecessors. 

Several preventive measures may prevent clone attacks. First, install into the client code 
blocks special guards that monitor whether the application software program code has become a 
cloned copy of the original. These guards are units of code that use methods known in the art to 
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check if some code relative to their current locations (the "code protection range") is different 
from before. They monitor their environments for clues about their positioning. 

A second preventative measure is to enlarge the code protection range so that the range 
covers a larger number of predecessors of the originally protected code. This allows more guards 
5 to be installed within the range and increases the cost of tampering with the region. 

A third preventative measure is to obscure by code disguise and obfuscation techniques 
the control flow both preceding and within the code protection range as much as possible. This 
is to prevent an attacker from knowing the locations of the immediate predecessors of his original 
target since these predecessors must be modified in order to transfer control to the clone. 
10 A final preventative measure is to avoid placing critical code containing sensitive 

instructions or data near the beginning of the execution flow, where it is not reachable from the 
rest of the code, since such code contains a limited number of basic blocks and is very vulnerable 
to clone attacks. 

An embodiment of the method of instalhng SPC according to the present invention is 
15 shown in FIG, 26. The method begins with a set of application software program files written in 
an assembly language. The first step shown in FIG. 26 is preprocessing the input code from the 
application assembly language software program files to enable efficient code transformations at 
a later stage of the process. The step is comprised of two concurrent operations. First, a 
combined CFG is built from the set of assembly language software program files. At the same 
20 time, instructions within the assembly language software program files containing high-level 
semantics are replaced by groups of simpler instructions with the equivalent semantics. The 
table in FIG. 27 illustrates several examples where the high-level semantics shown in the left 
column of the table are replaced by groups of simpler instructions with the same semantics 
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shown in the right column. INTEL® assembly code is used in FIG. 27, however the method of 
the present invention will work equally well with other, different hardware architectures and 
assembly language code. 

The second step shown in FIG. 26 involves installing self-protecting mechanisms. Self- 

5 protection is achieved by installing at least one guard into the application assembly language 
software program code. Self-protection may be enhanced by installing more than one guard to 
form a network of guards that cooperatively defend the application software program from 
modification. Further enhancement of self-protection may be achieved by applying a sequence of 
simple disguise and obfuscating transformations to the application assembly language software 

10 program code that protect the code and render the code unintelligible without compromising its 
functionality. ' 

In the embodiment of the present invention shown in FIG. 26, three distinct operations 
comprise the step of installing self-protection mechanisms. First, the appHcation assembly 
language software program code is disguised to obfuscate the appearance of the original code as 

15 much as possible before the installation of guards. Second, at least one guard is installed into the 
obfuscated code according to a protection scheme that may be given by the user, or may be 
generated automatically. Third, the code undergoes a second disguise operation to blend the 
guard code with the application assembly language software program code. 

The third step shown in FIG. 26 involves embedding at least one watermark and 

20 producing a software program file. This step is optional, and may not be required in every 
' implementation of this embodiment. When used, at least one watermark is embedded into the 
application assembly language software program code and protected by guards. After watermark 
insertions, a randomized listing of the software program basic blocks is written to a new file. 
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which is to be assembled in the next stage. The new randomized Usting will not rearrange the 
basic blocks that have already been protected, as they were grouped together and their relative 
positions were fixed during the previous guard installation stage. This avoids unexpected 
changes in values of parameters belonging to the guards already installed in the application 
5 assembly language software program code. 

The fourth step shown in FIG. 26 involves assembling the file and linking the file with 
other resources. The new assembly file produced fi*om the previous stage is assembled and its 
object file may be linked with other object files or libraries in order to produce a preliminary 
binary executable image, 

10 The fifth step shown in FIG. 26 involves patching the preliminary binary executable 

image with data values which any checksumming guards will use in determining checksum 
correctness. During the previous installation of checksumming guards some binary information, 
for example, checksums of client code blocks in the finahzed image, was not available and 
corresponding slots in the code for storing the values were left unfilled. This stage, therefore, 

15 computes the missing values based on the preliminary binary executable image and then patches 
them into the unfilled slots in the file. 

The patching process is comprised of several steps. First, an external simulator program 
of a type known in the art is used to execute the checksumming template of each installed 
checksumming guard, deriving one or more checksums for each client code block guarded by a 

20 checksumming guard in the preliminary binary executable image. This checksum is called the 
"checksum constant" of the client code block. In one embodiment of the present invention, the 
checksum constants are patched into the file in the appropriate place in the preliminary binary 
executable image, and used by the checksumming guards to compare dynamically the checksums 
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computed by the checksumming templates during program execution. In another embodiment of 
the present invention, a subset of the checksum constants, with each subset containing at least 
one checksum constant, are used to drive a functional algorithm which derives other values that 
in turn are patched into the file in the appropriate place in the preliminary binary executable 
5 image. These derived values and the functional algorithm are used by the checksumming guards 
to compare dynamically the checksums computed by the checksumming templates during 
program execution. To ensure that checksums are computed correctly, the order in which values 
are patched to the preliminary binary executable image follows the sequence of checksumming 
guard creations. This stage produces a binary executable application software program. 

10 The sixth step shown in FIG. 26 involves removing symbol tables fi"om the binary 

executable application software program. All symbol tables in the finalized code are removed. 
Their presence may give hints to attackers about the underlying self-protecting mechanisms. 

The final step shown in FIG. 26 involves attaching additional information to the binary 
executable application software program file. For the convenience of both the vendor and users 

15 of the self-protecting software program, a digital signature of the file and any encrypted 
customization parameters used in the installation process, may be attached to the end of the file 
as shown in FIG. 28. 

The digital signature provides an option for an application software program user to 
verify integrity of an application software program that came fi-om an unknown, possibly hostile 
20 source. There are many digital signature schemes available, any of which can be applied here. 
For example, digital signatures by public-key cryptography and one-way functions may be used. 
Note that the digital signature may cover both the software program code (the first portion of the 
file) and any encrypted customization parameters (the second portion). 
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Customization parameters are encrypted by using a secret key known only to the vendor 
or author of the software program. The specific set of customization parameters that guided the 
installation process may be stored in the same file for future reference. There may be no need for 
the vendor to store the parameters in a database. 

5 FIG. 29 shows a table illustrating the actions of a hypothetical self-protecting software 

program which produces incorrect results whenever its code is altered, even on inserting a single 
null instruction into the code. The table in FIG. 29 illustrates a self-protecting software program 
requires the correct password "opensesame" to generate the next prime number of a given 
number. The left column of the table in FIG. 29 illustrates the execution of the unaltered self- 

10 protecting software program, first when the wrong password is used and then when the correct 
password is used. The right column of the table in FIG, 29 illustrates the operation of the self- 
protecting software program after it has been altered by a hacker. On the first use, the altered 
self-protecting software program retums an erroneous value which may or may not be apparent to 
the hacker. After further alterations by the hacker, the altered software program terminates 

15 unexpectedly. 

FIG. 30 shows a block diagram illustrating the operation of one embodiment of a system 
for creating tamper resistant software according to the present invention. The box in FIG. 30 
labeled "The SPC System" represents a software program for creating a tamper, resistant 
application software program according to the present invention. The SPC System receives the 
20 input necessary to carry out the present invention, the input including but not limited to: (1) at 
least one assembly language software program to be protected, (2) optionally, a set of watermarks 
to be embedded into the assembly language software programs, (3) a set of object files or 
libraries with which the set of assembly language software programs will be linked, and (4) the 



P00620-US-01 



131 



customization parameters required by the present invention. The SPC System possesses a means 
for receiving more than one assembly language software program file as an input, including a 
means known in the art for resolving conflicting entity names may which may appear in different 
assembly language software program files, and a means known in the art for combining the more 

5 than one assembly language software program files. The SPC System installs Self-Protecting 
Code into the assembly language software programs in accordance with the present invention. 
The output of The SPC System will be a self-protecting binary executable software program, 
optionally having secure watermarks. 

Li an embodiment, the present invention may include a software means known in the art 

10 for storing references to one or more code blocks within an application software program to be 
protected by guards, and a means for later retrieving the stored references to the one or more code 
blocks. Such means will improve the efficiency of the present invention when the present 
invention is used by a user to protect an application software program which is under 
development. The user will not be required to identify code blocks to be protected each time the 

15 application software program is built fi-om its component program files. 

In an embodiment, the present invention may include a data storage and retrieval means 
known in the art for storing references to one or more guards installed in an application software 
program, and a means for later retrieving the stored references to the one or more guards. Such 
means will improve the efficiency of the present invention when the present invention is used by 

20 a user to protect an application software program which is under development. The user will not 
be required to reinstall guards each time the application software program is built fi-om its 
component program files. 
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In an embodiment, the present invention may provide the user the option of specifying a 
desired level of protection for the application software program. For example, the user may 
specify that the software protection level be "low," "medium," or "high," or the user may specify 
the exact number of guards to be installed, and/or may specify the complexity of the guards to be 
5 installed. Additionally or alternatively, the user may specify that the code disguise level be 
"low," "medium," or "high." Such specifications may be made through a user interface. The 
present invention will be operable to accept these user specifications and generate a self- 
protecting binary executable software program in accordance with these user specifications, by, 
for example, varying the number and complexity of the embedded guards. 

10 Li an embodiment, the present invention is operable to receive an appUcation software 

program, and to create protected copies of the executable version of the appUcation software 
program which are protected differently. Differently protected copies of the application software 
program are achieved by varying the application of one or more of the different methods 
disclosed herein. For example: (i) different client code blocks in each copy of the application 

15 software program may be selected; (ii) different guard formations may be installed in each copy 
of the application software program; (iii) different checksumming templates may be installed in 
each copy of the application software program; (iv) the same checksumming template may be 
installed in each copy of the application software program, but the location within the application 
software program code where the checksumming template is installed may be different in each 

20 copy of the application software program; (v) different conditional identities may be installed in 
each copy of the application software program; (vi) the conditional identities may be installed in 
different locations in each copy of the application software program; (vii) different code disguise 
techniques, in different sequences, and for different numbers of iterations may be applied to each 



P00620-US-01 



133 



copy of the application software program; (viii) where CFG-merging is employed, different code 
blocks in each copy of the application software program may be selected for merging; (ix) where 
CFG-cloning is employed, different basic blocks in each copy of the application software 
program may be selected for cloning; (x) where data-aliasing is employed, different constant data 
values in each copy of the application software program may be selected; (xi) where data 
preconiputation is employed, different computations for initializing the variables to be 
precomputed may be installed into the application software program code; (xii) the basic blocks 
of the appUcation software program may be arranged in a different sequence in each copy of the 
application software program; (xiii) different watermarks may be installed in each copy of the 
application software program; and/or (xiv) the same watermark may be installed in each copy of 
the application software program, but the location within the application software program code 
where the watermark is installed may be different in each copy of the application software 
program. Other ways of varying the application of one or more of the different methods 
disclosed herein for the purpose of generating differently protected copies of the application 
software program may be used in addition to, or in lieu of, the foregoing examples. 

An embodiment of the present invention may include a means for providing the user the 
option of protecting each copy of the application software program differently. If the user so 
opts, this embodiment may generate the differently protected copies of the application software 
program randomly and automatically, or may provide the user with the ability to generate the 
differently protected copies of the application software program under the control of the user. If 
the user does not desire differently protected copies of the application software program, this 
embodiment may be operable to create identically protected copies of the application software 
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program randomly and automatically, or may provide the user with the ability to generate the 
identically protected copies of the application software program under the control of the user. 

An embodiment of the present invention can be adapted to guard relocatable code (such 
as Windows DLL files) as well as regular non-relocatable code (such as executable files). 

5 Relocatable code is ordinary executable code except that it also contains information that allows 
the code to be loaded into (i.e., relocated to) different memory addresses at different program 
loading times. To make code relocation possible, the loader will patch location-dependent bytes 
in the program (such as target addresses of branch instructions) with values that depend on the 
actual memory location where the code is loaded. As a result, the values of these patched (or 

10 "fixup") bytes are not known until the program loading time, and these bytes may change from 
one program execution to another. 

Because the values of the fixup bytes are unknown at guard installation time, the fixup 
bytes must not be checksummed by checksumming guards. That is, instead of checksumming a 
segment of code containing fixup bytes, for relocatable code the system of the present invention 

15 checksums subranges of the relocatable code that do not contain the fixup bytes. By installing 
checksumming guards at the assembly or binary level, the system can know exactly what fixup 
bytes to skip over while still protecting the integrity of the relocatable code. 

Another embodiment of a guard according to the present invention is called an "external 
guard." Like the other guard embodiments discussed herein, an external guard is installed in an 

20 application software program. However, the fiinction of an external guard is not exclusively the 
protection of the application sofl:ware program in which it is installed. An external guard differs 
from other guards discussed herein in that at least one client code block of an external guard is 
not part of the application software program. The at least one "external" client code block of an 
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external guard may be, for example, all or a portion of another application software program, or 
all or a portion of a computer file which is not part of the application software program in which 
the external guard is installed. In an embodiment, an external guard may have the features of a 
checksumming guard according to the present invention. In an embodiment, an external guard 
may have the features of a silent guard according to the present invention. In an embodiment, an 
external guard may have the features of a repair guard according to the present invention. 

Another embodiment of an external guard is called a "policy-enforcement" guard. The 
function of a policy-enforcement guard according to the present invention is to enforce a certain 
policy for the computing platform upon which the application software program is running. For 
example, it may be desired by an employer to prevent employees from having instant messaging 
software on the employees' computers. This policy would be embodied in a computer file (a 
"policy file"), encrypted using a private key, and stored on the hard drive of the employees' 
computers. A policy-enforcement guard then is operable to retrieve a policy file, decrypt it using 
a public key, and verify whether any instant messaging software exists on the personal computer 
in violation of the policy. Optionally, the policy-enforcement guard may be operable to delete 
the offending instant messaging software from the personal computer. In the event that the 
policy is changed to allow a particular instant messaging software product, but other instant 
messaging software is not allowed, the revised policy file containing this information may be 
read and enforced by the same policy-enforcement guard. 

The present invention may be integrated with a source code compiler software program or 
a linker software program used in the art to generate assembly language and/or binary executable 
software programs from application software program source code written in a high level 
programming language. In this embodiment the user may, optionally, select through a user 
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interface those portions of the high level appHcation software program source code to be 
protected, such as, for example, specific procedures, functions, routines, or lines of code, by at 
least one guard before compiling the application software program, and the compiler and present 
invention will be operable to generate a self-protecting binary executable software program with 
5 at least one guard installed in the locations in the binary executable code which correspond to the 
designated locations in the high level source code. 

The method and system of the present invention provide a method and a system for 
protecting a application software program fi*om unauthorized modification which do not require 
special hardware or code encryption and decryption. The method and system also do not require 
10 special operating system features for proper execution. The defensive actions taken according to 
the present invention in response to software tampering may produce subtle errors rather than 
immediate program failure, thereby hindering the efforts of hackers to unauthorizedly modify a 
guarded application software program. 

The system of the present invention may be incorporated into or integrated with a 
15 programming language compiler for automatically generating self-protecting software programs, 
providing enhanced advantages for an author or vendor of a software program. 

Those of skill in the art will appreciate that the various means recited herein and in the 
claims may be performed by computer software and/or computer hardware. Such computer 
software may be written in a high-level programming language such as, for example, Java, C, 
20 C+-I-, Pascal, or Fortran. 

hi interpreting the matheniatical expressions contained herein, the following precedence 
of operations shall apply: (1) functions, such as, for example, H(Wy) or E(Rj); (2) exponentiation; 
(3) multiplication and division; and (4) addition, subtraction, and modulo division. When 
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multiplication and division occur together in an expression, each operation is evaluated as it 
occurs from left to right. Likewise, when addition, subtraction, and modulo division occur 
together in an expression, each operation is evaluated as it occurs from left to right. Where used, 
parentheses enclosing one or more operations affect the precedence of operations in the 
customaiy manner. 

The terms "random" and "randomly" and "randomized" and "randomization" when used 
herein mean that no apparent pattem is present in that activities associated with such terms. The 
use of such terms does not necessarily imply the use of a uniform distribution or of any other 
well known statistical distribution. 

While this invention has been described as having a preferred design, the present 
invention can be further modified within the scope and spirit of this disclosure. This application 
is therefore intended to cover any variations, uses, or adaptations of the invention using its 
general principles. For example, the methods disclosed herein and in the appended claims 
represent one possible sequence of performing the steps thereof. A practitioner of the present 
invention may determine in a particular implementation of the present invention that multiple 
steps of one or more of the disclosed methods may be combinable, or that a different sequence of 
steps may be employed to accomplish the same results. Each such implementation falls within 
the scope of the present invention as disclosed herein and in the appended claims. Furthermore, 
this application is intended to cover such departures from the present disclosure as come within 
known or customary practice in the art to which this invention pertains and which fall within the 
limits of the appended claims. 
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